Example : jscookmenu, popup, popup calendar, htmEditor, ...
Also, to handle files upload - this is the multipart - part - of the filter.
In your tree2 component for example, you have :
if (_javascript_Location == null)
{
AddResource.addJavaScriptHere(HtmlTreeRenderer.class, "_javascript_/tree.js", context);
AddResource.addJavaScriptHere(HtmlTreeRenderer.class, "_javascript_/cookielib.js", context);
}
So, if no alternative _javascript_ location is provided, it'll pickup the ones bundled within myfaces' jar.
We could rewrite all those components to also support _javascript_Location, but I don't see any benefit in doing this.
It would only tangle unrelated codes (application code and components code). It would make it very difficult (almost impossible in some cases) to evolve the component's design without breaking existing applications, as we would have to support legacy _javascript_s that are embeded into the applications.
So, yes, we can avoid it (in fact we did until we wrote this ExtensionsFilter), but it is a very bad idea.
On Mon, 2005-03-14 at 22:44 -0500, Sean Schofield wrote:
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 > > > >
