myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mart...@apache.org>
Subject RE: Split (or kill) Extensions filter
Date Tue, 15 Mar 2005 00:16:46 GMT


On Mon, 14 Mar 2005, Sylvain Vieujot 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 ?

We used this approach in a recent release of a large web app at my day 
job. It works out really well, because the browser only ever asks for a 
resource once until you upgrade to a later version, at which point the 
browser automatically gets the latest version, again only once. Very 
effective.

--
Martin Cooper


> 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:oliver@tuxerra.com]
>>> 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
>

Mime
View raw message