You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Claude Brisson <cl...@renegat.net> on 2007/02/26 01:05:49 UTC
[Tools] Some proposals for Tools 2.0
Hi there!
Here are some structural evolutions I'd like to discuss before any
coding. I'm pretty sure that the first one is a good option - the second
one is more prospective.
1. On-demand tools loading: instead of a standard HashMap, the idea here
is to have a ToolMap, inheriting HashMap, which will instanciate a tool
from its toolinfo only when the generic getter is called. This should be
a quite interesting performance gain in some situations. We maybe need
some attribute to have tools instanciated at toolbox initialization
('instanciate-on-load' ?).
2. View tools: other objects in my webapp are often jealous of the view
servlet. They also would like to use some of the tools. Session scoped
tools can be reached via the session, but it's not the case for
application or request scoped tools. To achieve this, there would be two
things to do:
- the application tools map should be stored as a ServletContext
attribute and the request tools map as a Request attribute.
- the constitution of the three scoped maps should be decorrelated from
the remaining of the processing so that it could potentially take place
in a servlet filter.
Thanks for your remarks,
Claude
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Tools] Some proposals for Tools 2.0
Posted by Nathan Bubna <nb...@gmail.com>.
On 3/23/07, Christopher Schultz <ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Nathan,
>
> Nathan Bubna wrote:
> > On 3/23/07, Christopher Schultz <ch...@christopherschultz.net> wrote:
> >> I think a better architecture would be to create a helper class that is
> >> called by either VelocityViewServlet or VelocityToolboxFilter (a better
> >> name IMHO), instead of actually initializing a VelocityViewServlet
> >> inside the filter just for the purposes of accessing a
> >> "prepareToolboxes" method.
> >
> > like this one?
> > http://svn.apache.org/viewvc/velocity/tools/branches/2.x/src/main/java/org/apache/velocity/tools/view/VelocityView.java?view=markup
> >
> > i never said anything about initializing a servlet within a filter. ;-)
>
> Sorry, it was this line that threw me:
>
> >>> 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.
>
> For some reason, I was thinking that VelovityView was the servlet. It
> looks like VelocityView was similar to the utility class that I was
> envisioning.
great. easy mistake. VelocityView does a lot of what the
VelocityViewServlet used to handle. :)
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGBEUK9CaO5/Lv0PARAvQeAJ9mvVtIwN6MkoiE6y9XBvngJVsTCACeMjKV
> pDNSmYfPUY3ZUY52m1Za0Vk=
> =wJ8l
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Tools] Some proposals for Tools 2.0
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nathan,
Nathan Bubna wrote:
> On 3/23/07, Christopher Schultz <ch...@christopherschultz.net> wrote:
>> I think a better architecture would be to create a helper class that is
>> called by either VelocityViewServlet or VelocityToolboxFilter (a better
>> name IMHO), instead of actually initializing a VelocityViewServlet
>> inside the filter just for the purposes of accessing a
>> "prepareToolboxes" method.
>
> like this one?
> http://svn.apache.org/viewvc/velocity/tools/branches/2.x/src/main/java/org/apache/velocity/tools/view/VelocityView.java?view=markup
>
> i never said anything about initializing a servlet within a filter. ;-)
Sorry, it was this line that threw me:
>>> 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.
For some reason, I was thinking that VelovityView was the servlet. It
looks like VelocityView was similar to the utility class that I was
envisioning.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGBEUK9CaO5/Lv0PARAvQeAJ9mvVtIwN6MkoiE6y9XBvngJVsTCACeMjKV
pDNSmYfPUY3ZUY52m1Za0Vk=
=wJ8l
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Tools] Some proposals for Tools 2.0
Posted by Nathan Bubna <nb...@gmail.com>.
On 3/23/07, Christopher Schultz <ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Nathan,
>
> Nathan Bubna wrote:
> > 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 think a better architecture would be to create a helper class that is
> called by either VelocityViewServlet or VelocityToolboxFilter (a better
> name IMHO), instead of actually initializing a VelocityViewServlet
> inside the filter just for the purposes of accessing a
> "prepareToolboxes" method.
like this one?
http://svn.apache.org/viewvc/velocity/tools/branches/2.x/src/main/java/org/apache/velocity/tools/view/VelocityView.java?view=markup
i never said anything about initializing a servlet within a filter. ;-)
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGBA8N9CaO5/Lv0PARAmNeAKCfiZ9jMenTeRt0YlV8G2VPF6BGPgCfQeyN
> uewxL04gwK9RLmQIhVpB4m4=
> =VRUm
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Tools] Some proposals for Tools 2.0
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nathan,
Nathan Bubna wrote:
> 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 think a better architecture would be to create a helper class that is
called by either VelocityViewServlet or VelocityToolboxFilter (a better
name IMHO), instead of actually initializing a VelocityViewServlet
inside the filter just for the purposes of accessing a
"prepareToolboxes" method.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGBA8N9CaO5/Lv0PARAmNeAKCfiZ9jMenTeRt0YlV8G2VPF6BGPgCfQeyN
uewxL04gwK9RLmQIhVpB4m4=
=VRUm
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Tools] Some proposals for Tools 2.0
Posted by Nathan Bubna <nb...@gmail.com>.
On 3/22/07, Claude Brisson <cl...@renegat.net> 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Tools] Some proposals for Tools 2.0
Posted by Claude Brisson <cl...@renegat.net>.
Le jeudi 22 mars 2007 à 09:26 -0700, Nathan Bubna a écrit :
> ok, so i started working on this last week, and got further than
> anticipated. this week, i've had a little time to refine some things,
> so i want to start checking stuff in a bit later today. i've probably
> already done more than i ought to have without checking stuff in.
Glad to hear that!
> at this point, i'm not thinking extensively about backwards
> compatibility, but i do hope to address that eventually. i just
> wanted to give a little heads up that some of this stuff is going to
> start coming into the 2.x branch today. also, please note that it
> compiles with jdk 1.5 and velocity 1.5, but is not yet fully useable
> nor have i written tests for the new stuff yet. i do plan to write
> tests, and i'm thinking about jdk 1.4 support as well. i'm not
> planning to support pre-1.5 Velocity though.
>
> feedback is welcome, as are contributions.
I stay tuned... My daytime job is currently quite demanding, but April
should be much more quiet.
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.
Claude
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Tools] Some proposals for Tools 2.0
Posted by Nathan Bubna <nb...@gmail.com>.
On 2/26/07, Nathan Bubna <nb...@gmail.com> wrote:
> On 2/25/07, Claude Brisson <cl...@renegat.net> wrote:
> > Hi there!
> >
> > Here are some structural evolutions I'd like to discuss before any
> > coding. I'm pretty sure that the first one is a good option - the second
> > one is more prospective.
> >
> > 1. On-demand tools loading: instead of a standard HashMap, the idea here
> > is to have a ToolMap, inheriting HashMap, which will instanciate a tool
> > from its toolinfo only when the generic getter is called. This should be
> > a quite interesting performance gain in some situations. We maybe need
> > some attribute to have tools instanciated at toolbox initialization
> > ('instanciate-on-load' ?).
>
> I really like the idea! Though, i think i might prefer to call it a
> Toolbox instead of ToolMap. just to stick with the metaphor... :)
>
> > 2. View tools: other objects in my webapp are often jealous of the view
> > servlet. They also would like to use some of the tools. Session scoped
> > tools can be reached via the session, but it's not the case for
> > application or request scoped tools. To achieve this, there would be two
> > things to do:
> > - the application tools map should be stored as a ServletContext
> > attribute and the request tools map as a Request attribute.
> > - the constitution of the three scoped maps should be decorrelated from
> > the remaining of the processing so that it could potentially take place
> > in a servlet filter.
>
> i agree we should find a way to solve this, though i'm not sure i
> fully understand the second part of your proposed implementation. i
> would think we would simply want to create a Toolbox (as in idea #1)
> for each scope, place the proper Toolbox in the attributes of the
> request/session/servletcontext and then just make our ChainedContext
> smart enough to search in all of those for tools that are requested.
> i don't see why we need a filter or to constitute the three toolboxes
> at all.
>
> oh, and with this, we may want to re-organize the layout of a
> toolbox.xml file to lump the tools from the three scopes together in
> their toolboxes. but that's a separate issue...
>
> i predict there are going to be some interesting complications/side
> effects, but we'll be able to see those better once we start coding.
>
> i'll try and get a 2.x branch set up today (or soon, if i don't get to
> it). Then we can start hacking away. i have some other ideas and
> major changes in mind and already have some code for them too. i'm
> excited about the possibilities...
ok, so i started working on this last week, and got further than
anticipated. this week, i've had a little time to refine some things,
so i want to start checking stuff in a bit later today. i've probably
already done more than i ought to have without checking stuff in.
at this point, i'm not thinking extensively about backwards
compatibility, but i do hope to address that eventually. i just
wanted to give a little heads up that some of this stuff is going to
start coming into the 2.x branch today. also, please note that it
compiles with jdk 1.5 and velocity 1.5, but is not yet fully useable
nor have i written tests for the new stuff yet. i do plan to write
tests, and i'm thinking about jdk 1.4 support as well. i'm not
planning to support pre-1.5 Velocity though.
feedback is welcome, as are contributions.
oh, and in case anyone is concerned, i have no plans to stop
developing the 1.x branch. i'm just exploring the possibilities for
2.x.
> > Thanks for your remarks,
> >
> >
> > Claude
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> > For additional commands, e-mail: dev-help@velocity.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Tools] Some proposals for Tools 2.0
Posted by Nathan Bubna <nb...@gmail.com>.
On 2/25/07, Claude Brisson <cl...@renegat.net> wrote:
> Hi there!
>
> Here are some structural evolutions I'd like to discuss before any
> coding. I'm pretty sure that the first one is a good option - the second
> one is more prospective.
>
> 1. On-demand tools loading: instead of a standard HashMap, the idea here
> is to have a ToolMap, inheriting HashMap, which will instanciate a tool
> from its toolinfo only when the generic getter is called. This should be
> a quite interesting performance gain in some situations. We maybe need
> some attribute to have tools instanciated at toolbox initialization
> ('instanciate-on-load' ?).
I really like the idea! Though, i think i might prefer to call it a
Toolbox instead of ToolMap. just to stick with the metaphor... :)
> 2. View tools: other objects in my webapp are often jealous of the view
> servlet. They also would like to use some of the tools. Session scoped
> tools can be reached via the session, but it's not the case for
> application or request scoped tools. To achieve this, there would be two
> things to do:
> - the application tools map should be stored as a ServletContext
> attribute and the request tools map as a Request attribute.
> - the constitution of the three scoped maps should be decorrelated from
> the remaining of the processing so that it could potentially take place
> in a servlet filter.
i agree we should find a way to solve this, though i'm not sure i
fully understand the second part of your proposed implementation. i
would think we would simply want to create a Toolbox (as in idea #1)
for each scope, place the proper Toolbox in the attributes of the
request/session/servletcontext and then just make our ChainedContext
smart enough to search in all of those for tools that are requested.
i don't see why we need a filter or to constitute the three toolboxes
at all.
oh, and with this, we may want to re-organize the layout of a
toolbox.xml file to lump the tools from the three scopes together in
their toolboxes. but that's a separate issue...
i predict there are going to be some interesting complications/side
effects, but we'll be able to see those better once we start coding.
i'll try and get a 2.x branch set up today (or soon, if i don't get to
it). Then we can start hacking away. i have some other ideas and
major changes in mind and already have some code for them too. i'm
excited about the possibilities...
> Thanks for your remarks,
>
>
> Claude
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org