On 3/22/07, Claude Brisson <[EMAIL PROTECTED]> wrote:
Le jeudi 22 mars 2007 à 09:26 -0700, Nathan Bubna a écrit :
<snip/>
Oh, responding to one of your previous points:
> > i don't see why we need a filter or to constitute the three toolboxes
> > at all.
It's a need I frequently encountered. Quite simple in fact. If the
toolbox manager can be initialized before the view servlet is reached
(and for instance from an early filter but the filter itself need not to
be provided), then other objects in the webapp (other filters,
controller objects) can reach constants and tools defined in the three
toolboxes. It just boils down to avoid re-initializing one of the three
toolboxes when we read the view servlet.
Take a look at what i've done so far, when you get a chance. We're
close to what you want already, i think. The VelocityView class can
be easily used in a filter as it is, and once we have the toolboxes in
the request/session/application attributes, then we can access them
from any servlet or filter. So, we would just need to create a
VelocityViewFilter that initializes the VelocityView when it is
init'ed, and then calls velocityView.prepareToolboxes(request) for
every request it handles.
I'm about to check in some refinements to the prepareToolboxes() stuff
(to control the key used to store the toolboxes, so they can be shared
or unique to the VelocityView.
We might also consider supporting the option of putting the
initialized VelocityView into the application attributes so that any
Filter/Servlet/Tag can share it, rather than having to initialize
their own. This would be more efficient than the current approach of
just sharing Toolboxes between VelocityViews.
there are many ways to skin this cat. the trick will be choosing the
best as a default, and making it easy to do things differently.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
