-
Notifications
You must be signed in to change notification settings - Fork 19
Relative Resources #947
Comments
Reported by @edburns |
Issue-Links: |
jakobkorherr said: |
jakobkorherr said: {resource['org.site.lib/images/background.png']} ) out of url(../images/background.png). This shows the big impact of this issue, I think. See http://wiki.icefaces.org/display/ICE/ACE+CSS+URL+Mapping for more details! We seriously need to fix this with JSF 2.2! Such (annoying) preprocessing should not be necessary. |
dueni said: it would be usefull if there was a way to specify resources depending on the active ProjectStage - e.g. for css and Javascript files, to allow using packaged resources normally but uncompressed css/javascript when ProjectStage is set to Development. I was discussing this once with someone and we ended up in a possible solution for that to put additional includeProjectStage/excludeProjectStage condition attributes on @ResourceDependency annotation and probably also same attributes on outputStylesheet/outputScript tags. Might be this ends up in an additional independent issue, but as you are going to work on ResourceHandling anyway I feel adding it here is ok. regards |
lu4242 said: I believe that it could be more simple to assume a "mirror uncompressed" location, and in practice use some plugin to compress the resources, and add the logic on the default (or custom) ResourceHandler algorithm. EB> This approach breaks down when there is not a 1:1 mapping between |
jakobkorherr said: This is a very, very nice idea! I will prototype that in my relative-resource-handler at apache-extras (see http://code.google.com/a/apache-extras.org/p/relative-resource-handler/). Also: Since I will have more time in the next two weeks, I really do hope to get some work done for the spec! Regards, |
dueni said: any progress here? I wanted to add something about the ProjectStage dependent resources. There might be two options for it: 1. use a project stage dependent resource path in the jar (similar to Locale handling with fallback). This is useful if the resource is the same name but only compressed for production, e.g.
2. because the JS files may get pretty big, we would like to use multiple JS files for development but combine/compress a number of such JS files to one for production. This means the number of resource dependencies change depending on project stage.
So for example, it should be possible to state one component needs funct-a.js and funct-b.js when in project stage Development and only funct-all.js when in project stage Production. I think possibility 1 is a little closer to what Leonardo mentioned about the MyFaces specific hack. Cheers |
jakobkorherr said: Currently I am trying to convince a professor at Vienna university of technology to let me write about the relative resource handler for my bachelor thesis. If this will be accepted, I will have a lot more time for the resource handler. The idea is really very, very great and I'd like to do some prototyping here. However, I don't know if we should really follow a convention-over-configuration approach. I am actually not sure if we can find a convention for the resource name that will fit in most scenarios. Maybe we need some configuration mechanism here... Regards, |
dueni said: For multiple skins or theme support it will be necessary that the resource path may contain an optional skin or theme-path part.
The reference to this resource could be:
I have kind of such an implementation, but it is probably to much integrated with our Skin interface. It should be a more general solution. Regards |
jakobkorherr said: You are totally right! In my resource handler I called it "support for multi-tenancy", however, this is not implemented yet. Actually you need to add every information you need to determine the correct resource into the resource path, thus it somehow is a REST url. I also added a resource-version to the path in order to deal with resource-update-browser-cache problems. Regards, |
@edburns said: |
File: sample.zip |
jakobkorherr said: Your sample is somehow funny. You use a css file in webapp/resources/library/style.css using relative paths like this: url(../../included.css) and url(../../expert-draft-bg.png). The two referenced resources, of course, are located two folders up in the directory tree (directly in webapp). Now as it would seem to be logical that this works, it really is a coincidence. You see, style.css is loaded via the following url:
Thus, included.css and expert-draft-bg.png are loaded by the browser using the following urls:
The 1st ".." removed "javax.faces.resource" and the 2nd ".." removed "faces" (however, you would actually think that the 1st ".." removes library and the 2nd ".." removes "resources"). This, of course, only works because tomcat (or any other servlet container) serves the two files directly, and it has nothing to do with the JSF resource handler (e.g. ValueExpressions won't work!). Now, there are a number of possibilities to break the example:
I used the 2nd of the above options in my sample_broken.zip. Here, style.css still gets loaded via:
But now the browser tries to locate included.css and expert-draft-bg.png using these urls:
Which does NOT work, because the library request parameter is missing. My approach (http://code.google.com/a/apache-extras.org/p/relative-resource-handler/) creates an url in which the library is included in the url path, thus this will work. If you have any further questions, please ask! Regards, |
jakobkorherr said: |
File: sample_broken.zip |
@edburns said: Now I can proceed to better see how to fix it! |
@edburns said: META-INF/relative-resources.xml to declare libraries and we can't accept that requirement in the spec. Also, the stated limitation of only being able to work with prefix mapped JSF runtimes is unacceptable. I can see why you made these decisions and how they enable the nice features of your Relative ResourceHandler, but we need to figure out how to do what you request without making unacceptable compromises. |
jakobkorherr said: There are many reasons:
{resource[]} url references as errors. Every server (http or servlet container), CDN,... supports relative paths in the URLs like a normal file system, why should JSF do this differently?
I actually would not use the current JSF ResourceHandler because of these points and instead let tomcat (or even weblets) handle my resources, because they both support relative paths like a calm. |
@edburns said: Here's a clue, from RelativeResourceHandler#132. // skip version in url (first part, only there to avoid cache problems on updates) But that still doesn't answer my question. What does the 1.0.0 mean? Jakob's ResourceHandler.createResource() allows the entire resourceId to
Ok, let's say we make relative libraries the default for prefix mapped |
@edburns said: |
@manfredriem said: |
This issue was imported from java.net JIRA JAVASERVERFACES_SPEC_PUBLIC-947 |
Closing this as this issue is migrated to jakartaee/faces#947 |
https://issues.apache.org/jira/browse/MFCOMMONS-29
The features of this ResourceHandler include the following:
without using #resource['..'])
ProjectStage == Development)
In addition, it does NOT support ValueExpressions in resource files
for performance reasons.
The most important feature, in my opinion, is how the resource URL is
built, e.g. /faces/javax.faces.resource/de_AT/$/some/library/$/my/resource.css
... because it permits resources referencing other resources without
{resource['...']}
(e.g. css files referencing images or other css
files). With the standard ResourceHandler this is 1) annoying if you
have to change the files you get from your designer and 2) a
performance bottleneck, because resources with ValueExpressions are
not cached and also regenerated for each request.
Furthermore, the resource URL contains the locale and thus you have no
problems with cached resources if a users changes the locale, because
he/she will get a new URL and thus a new resource (the right one).
Affected Versions
[2.2]
The text was updated successfully, but these errors were encountered: