Q: Under what circumstances are myfaces users *required* to use the extensions filter?
sean On Mon, 14 Mar 2005 19:13:44 -0800, Korhonen, Kalle <[EMAIL PROTECTED]> wrote: > I agree with Sylvain, don't see a point in splitting it up (definitely > not for performance reasons only). > > Kalle > > ________________________________ > > From: Sylvain Vieujot [mailto:[EMAIL PROTECTED] > Sent: Monday, March 14, 2005 6:35 PM > To: MyFaces Development > Subject: Re: Split (or kill) Extensions filter > > > Yes, I don't think we should split off MultipartFilter from > ExtensionsFilter, for several reasons : > > 1) It will require to set 2 filters, which goes against the main > purpose of this filter, that is to keep things simple. > 2) A nice feature with the ExtensionsFilter would be to ensure > that the form has enctype="multipart/form-data" when it contains a file > upload component. > > If the reason you want to do this is performance, did you do any > benchmark ? > I would guess that the ExtensionsFilter doesn't impact > performance a lot. > I even think it would rather improve the client overall response > time as it includes the needed resources only when needed, and it (now) > provides better client side caching. > For example, if you have a page with a tab panel, and many > components on each tab, as you switch tab, it will only include the > needed resources. > The only drawback of the filter is the in-memory buffering of > the complete response, which is indeed a penalty for pages with no > complex setup. > > If you really need a MultipartFilter only, I rather recommend > adding a disableExtensions attribute to this filter, the same way it's > done for the uploadMaxFileSize attribute. > It keeps things simple while achieving the goal you have. Plus, > it's very easy to do. > You could also leave the ExtensionsFilter as it is, and write a > stripped down version, handling only the Multipart stuffs. > Anyway, I strongly think you should not oblige the user that > still want to use the ExtensionsFilter to setup 2 filters (one for > extensions and one for multipart). > > If you want to include the disableExtensions filter parameter, > just tell me, I can do that quickly. > > Thanks, > > Sylvain. > > On Tue, 2005-03-15 at 02:50 +0100, Oliver Rossmueller wrote: > > So from my POV there is consensus to split off > MultipartFilter from > ExtensionsFilter as proposed but to keep > ExtensionsFilter and give users > the choice to use it. If I missed an argument against > the split please > let me know. Otherwise I'll do the split until the end > of the week. > > Oliver > > 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 > > > >
