Sylvain, Take a look at what I did in tree2. There are tag attributes 'javascriptLocation' and 'imageLocation' (and 'styleLocation' if I had stylesheets) that can be used to provide alternate locations for these types of resources. So the user can copy them out of tree2/resources and put them wherever.
I think it would be good if we offer this option to users on all of our components that currently *require* extension filter. I haven't checked if any of them actually require it. There is also an alt_location_attributes.xml that one can use to modify their TLDs to do this. sean On Mon, 14 Mar 2005 09:38:35 -0400, Sylvain Vieujot <[EMAIL PROTECTED]> wrote: > Instead of setting the last-modified header, I was working on including the > jar build version (in fact, it's hash) in the URL, and setting a long > (default one week) expiry. > So, all the content is cached, and when you change your MyFaces jar, the > URL is different. > I think it would be better, as the browser will not even query for the > last-modified header, and a query will be saved. > Also, I don't know if we can get the last modified date from a file that's > in a jar. > > Any comment with this approach ? > > As stated on a previously, the code is ready, I just need to get the > implementation version. > Right now, AddResource.class.getPackage().getImplementationVersion() return > null. > > > > On Sun, 2005-03-13 at 21:06 -0800, Korhonen, Kalle wrote: > > -----Original Message----- > From: Oliver Rossmueller > [mailto:[EMAIL PROTECTED] > Subject: Split (or kill) Extensions filter > > I'm no longer willing to pay the runtime penalty > ExtensionFilter adds to > an application (javascript files > loaded over and over again, in-memory > buffering of the > complete response) just for the benefit of 10 minutes of > > saved developer time for adding the javascript stuff to the > header of > any jsf page. The only problem as I can see with the extensionsFilter is > that it doesn't currently send the last-modified header when sending a > resource. I've been meaning to patch it when I have some time for that, but > I'm more than happy if somebody else fixes it before I have a chance. That > saved 10 mins for every JSF developer quickly adds up and I strongly believe > that 10 mins is worth saving. > So my plan is to split up ExtensionFilter to > MultipartFilter > (in the form it was before ExtensionFilter was introduced) > > and ExtensionFilter (just dealing with extensions stuff). > Actually I > would like to drop the extensions stuff completely > as I don't see any > benefit in having this kind of filter at > hand. We could create a > myfaces-resources.jar instead where > we place all the image and javascript > resources so it's easy > to add all the resources to your war file by just > adding a > zipfileset tag to your build file. > Comments? Objections? > Personally, I think ExtensionsFilter is a pretty clever way of loading > packaged resources. Please consider evolutionary versus revolutionary > approach in this case as well. Kalle
