On Mon, 14 Mar 2005, Sylvain Vieujot wrote:

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.

Or you could base the filter on Commons Chain. This would give you a very general-purpose extension mechanism, so that you could configure out multipart of you don't need it, and configure in only what you need. No special purpose code, but general extensibility for the future and for custom applications.


--
Martin Cooper


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




Reply via email to