Thanks for your modifications !
I always have problems with i8n
I kept your speed improvements for the <head> body detection, but I search for head and HEAD before looking for the body, as if there is one head, we should really put the links there.
I made another change to the filter to be able to handle resource hierarchies.
That is, if you give a script the base URL for the resources, let's say blabla/images, then it'll be able to fetch everything bellow it : blabla/images/theme1/a.gif, ...
This is quite important as this enabled true transparent delivery, even when the resources are in the jar.
I use it quite heavily in a a new component I hope to commit by the end of the week and that has tens of scripts/images, ... (it's an HtmlEditor).
This can only be done using a filter, and you can't use resources hierarchies with a servlet because of the way to pass the parameters (you'll see, I changed that in my last post).
A downside though is that now, we have to add the /faces/* mapping to the ExtensionsFilter. That is, if you use the *.jsf scheme, the filter will need to have both mappings.
I write that in bold, as this is a modification you shouldn't forget in your applications.
Nevertheless, I think this downside is worth the pain.
I understand your worry for the caching of the resources.
Indeed, right now, the resources aren't cached.
I plan to add a parameter to the filter that would be the delay to cache the resources.
The filter will set an optional Expires to the response, to improve the caching.
It's not a perfect solution, but I used it in some projects, and once you've accepted the fact that it's not ideal, it turn out to be quite convenient.
I just use a delay of 0 on the development servers, and 3 days on the production servers.
For the split of the filter (multipart handling vs resource delivery), I'm not a great fan of this idea.
If you look at the code of the filter itself, you'll see that it's pretty clean, and quite light.
Also, a multipart request might need to have it's response altered by the resource delivery script if the form as components with resources.
So, we would in any case need the 2 filters.
In the end, I find that more complex for the user AND for the developer (us).
I find the current solution quite clean and simple to understand / implement for any MyFaces newbie.
Thanks for your help, and sorry for this long email.
Sylvain.
On Thu, 2004-12-02 at 02:09 +0100, Oliver Rossmueller wrote:
Sylvain, I was very interested in what you have done and had a look at your enhancements and it's cool stuff! Anyway I committed some modifications because of i18n issues and (hopefully) to improve performance a little bit. And there are two points I would like to discuss: 1) IMHO resource delivery and multipart handling should not be mixed up in one filter. I understand your intentions to keep configuration simple but serving embedded _javascript_ and css resources has nothing in common with multipart requests so we should keep these two aspects separated. It think we can ask our users to add an additional servlet filter to their web.xml for the benefit of simplified JSP and a simplified packaging process. 2) I would move resource delivery from the filter to a servlet so the filter just has to wrap the response object and perform the post-processing of the response. The advantage of a servlet-based solution is reduced server load. If getLastModified() is implemented in a usefull manner we don't have to stream a resource again if the browser already has the latest version. Another servlet would require for another servlet and servlet-mapping entry in web.xml, but again the benefit should be worth the effort to any user. So what do you think? Oliver Sylvain Vieujot wrote: > Yes, that's exactly what I'm doing. > When the code is comited, please review it though, because I'm not > sure I'm 100% correct in the setContentType, and all the i8n stuffs. > > Sylvain. > > On Wed, 2004-12-01 at 19:29 +0100, Manfred Geiler wrote: > >>Sylvain Vieujot wrote: >>> Ok, it works fine for the _javascript_s with the new filter. >>> >>> For the CSS, I'm working on a solution "a la SiteMesh" ( >>> http://www.opensymphony.com/sitemesh/ ). >>> This means in the filter, we capture the response, and before rendering >>> it, we include the relevant <link>, ... in the header. >> >>You could even wrap the response and redirect the standard response >>Writer through a special Writer, that includes the relevant <link> tags >>into the stream, before actually streaming it back to the client. >> >>> As SiteMesh is known to have quite good performance, I think it's an >>> acceptable solution. >>> >>> Any thoughts on this approach ? >> >>Cool solution, yes of course! >> >>Manfred >> >>
<<attachment: smiley-6.png>>
