The biggest drawback it has in that the resources aren't cached. I started to work on that this week-end, and hope to have this resolved during the week.
If you want to explicitly disable it, I've no problem with that, but please don't remove it.
It would make it almost impossible for me to maintain all the _javascript_s for the components in both MyFaces and my applications.
Thanks,
Sylvain.
By the way, does someone know how to get the Implementation Version from the jar file ?
I used implementationHash = AddResource.class.getPackage().getImplementationVersion().hashCode();
but the getImplementationVersion return null.
On Mon, 2005-03-14 at 00:38 -0500, Sean Schofield wrote:
I agree with Kalle that the extension filter is kind of cool. It has its drawbacks sure but I wouldn't throw it out just because there is a few issues. Perhaps we could split it apart in the manner that Oliver or Martin are suggesting. In tree2 I provide the user the option of using the extension filter or specifying their own locations for _javascript_ and images. Ultimately the more choices the user has the better. sean On Sun, 13 Mar 2005 21:20:14 -0800 (PST), Martin Cooper <[EMAIL PROTECTED]> wrote: > First off, I know next to nothing about this filter, other than reading a > few messages on this list, so feel free to take my comments with a grain > of salt. ;-) > > You could consider the approach that I believe Shale is taking, and base > the filter on Commons Chain. This lets people (a) configure only the > commands they need for a given application, and (b) write additional > commands to be plugged into the filter very easily. > > For the issue of _javascript_ files mentioned below, there are a couple of > things that can be done. First off is to ensure that the browser caches > the _javascript_ once it has it. Secondly, a very nice trick that Isomorphic > SmartClient uses is that a filter sits there waiting for requests for .js > files, and looks for a corresponding .js.gz file, returning that instead > if the browser supports gzip encoding. These two techniques, taken > together, resulted in massive performance gains in one of our > applications. > > My 2 cents... > > -- > Martin Cooper > > > On Mon, 14 Mar 2005, Oliver Rossmueller wrote: > > > 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. > > > > 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? > > > > Oliver > > > > -- > > Oliver Rossmueller > > Software Engineer and IT-Consultant > > Hamburg, Germany > > http://www.rossmueller.com > > > > >
