You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Mike Curwen <gb...@gb-im.com> on 2004/03/17 16:17:34 UTC
Best Practice for toolbox
Hi all,
I'm reading up on the velocity tools, and here's a snip from
http://jakarta.apache.org/velocity/tools/
"Also included is a Toolbox Manager which can automatically make
'view tools' and data available to the templates. Any class with
public methods can be used as a tool in the template."
The "and data" is what has sparked my imagination. I have a site that
does personalized pages. I'm porting it away from the old
velocityservlet, onto VVS. The site is fairly simple, and there's not a
huge amount of 'processing' involved by any sort of traditional "front
controller". The only thing the current controller does is examines the
unique id (in the session), and retrieves that user's personal info from
the database. It does this on every request.
So I'm thinking... hey...
<tool>
<key>client</key>
<scope>session</scope>
<class>com.gbim.util.ClientView</class>
</tool>
That class is something I'm already using in my current system. And just
by happy co-incidence, it was programmed with several public methods of
use to me.
So now, all I have to do is say: $client.name. And look at what I
just did.. I changed how often the class is instantiated , simply by
using 'session' scope, rather than request.
So esentially, I can completely eliminate my front controller! Just
call any of my velocity pages directly, and the toolbox will populate my
client object the one time per session. It's declaritive programming!
Should I be scared? Is this a 'best practice' use ? Something deep
inside is scared of it being this easy! ;)
-------------------------------------------
Mike Curwen 204-885-7733
Intermediate Programmer www.gb-im.com
-------------------------------------------
____ ____ ___ __ __
/ ___| | __ ) |_ _| | \/ |
| | _ | _ \ _____ | | | |\/| |
| |_| | | |_) | |_____| | | | | | |
\____| |____/ |___| |_| |_|
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Best Practice for toolbox
Posted by Nathan Bubna <na...@esha.com>.
Mike Curwen said:
...
> I have a site that
> does personalized pages. I'm porting it away from the old
> velocityservlet, onto VVS. The site is fairly simple, and there's not a
> huge amount of 'processing' involved by any sort of traditional "front
> controller". The only thing the current controller does is examines the
> unique id (in the session), and retrieves that user's personal info from
> the database. It does this on every request.
>
> So I'm thinking... hey...
> <tool>
> <key>client</key>
> <scope>session</scope>
> <class>com.gbim.util.ClientView</class>
> </tool>
>
>
> That class is something I'm already using in my current system. And just
> by happy co-incidence, it was programmed with several public methods of
> use to me.
> So now, all I have to do is say: $client.name. And look at what I
> just did.. I changed how often the class is instantiated , simply by
> using 'session' scope, rather than request.
in my company webapps that use VelocityTools, it's a pretty standard to have a
session-scoped "UserTool" that does pretty much what you describe. so i think
what you're doing is a good practice.
> So esentially, I can completely eliminate my front controller! Just
> call any of my velocity pages directly, and the toolbox will populate my
> client object the one time per session. It's declaritive programming!
>
> Should I be scared? Is this a 'best practice' use ? Something deep
> inside is scared of it being this easy! ;)
:)
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Best Practice for toolbox
Posted by Nathan Bubna <na...@esha.com>.
Mike Curwen said:
> Nathan Bubna said:
>
> <snip />
>
> > > ServletContext ctx = null;
> > > HttpSession session = null;
> > >
> > > String ds_string = null;
> > > String cid = null;
> > >
> > >
> > > if (obj instanceof ViewContext) {
> > > session = ((ViewContext)obj).getSession();
> > > ctx = session.getServetContext();
> > >
> > > ds_string = ctx.getInitParameter("sys_datasource");
> > > cid = (String)session.getAttribute("cid");
> > > }
> >
> > // simplified...
> > ViewContext vc = (ViewContext)obj;
> > String ds_string =
> > vc.getServletContext().getInitParameter("sys_datasource");
> > String cid = (String)vc.getAttribute("cid");
>
> Heh.. yah, I only breezed over the docs for ViewContext, and I 1/2
> saw-1/2 imagined that there was a getSession(), because I saw getRequest
> and getResponse and getServletContext() aka 'application'. my bad. The
> code is now:
>
> session = ((ViewContext)obj).getRequest().getSession();
> ctx = session.getServletContext();
you still don't need to get the servlet context from the session. you can get
it straight from the ViewContext. but it doesn't really matter either way.
:)
> But how about that? a getSession() method on ViewContext. It can return
> null if no valid session (it would never create one).
hmm. maybe. i'll think about it.
> There is a filter in place to prevent people without sessions from
> getting to the VVS, so sessions and cid in that session are 'guaranteed'
> by other code. I shouldn't need to look for them elsewhere, and in fact,
> don't want to. That's why I avoided vc.getAttribute(). (I don't want
> people to be able to request: http://foo.com/index.vm?cid=777 and then
> get someone else's data.)
quite true.
and on a related note, you should also set
<create-session>false</create-session> in your toolbox, so that the
ServletToolboxManager will not create any session tools unless a session
already exists. by default, if you declare session-scope tools and there is
still no session by the time the request gets to the toolbox manager, it will
create a session for your session tools.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
RE: Best Practice for toolbox
Posted by Mike Curwen <gb...@gb-im.com>.
response below...
> -----Original Message-----
> From: Nathan Bubna [mailto:nathan@esha.com]
> Sent: Wednesday, March 17, 2004 10:51 AM
> To: Velocity Users List
> Subject: Re: Best Practice for toolbox
>
<snip />
> > ServletContext ctx = null;
> > HttpSession session = null;
> >
> > String ds_string = null;
> > String cid = null;
> >
> >
> > if (obj instanceof ViewContext) {
> > session = ((ViewContext)obj).getSession();
> > ctx = session.getServetContext();
> >
> > ds_string = ctx.getInitParameter("sys_datasource");
> > cid = (String)session.getAttribute("cid");
> > }
>
> // simplified...
> ViewContext vc = (ViewContext)obj;
> String ds_string =
> vc.getServletContext().getInitParameter("sys_datasource");
> String cid = (String)vc.getAttribute("cid");
Heh.. yah, I only breezed over the docs for ViewContext, and I 1/2
saw-1/2 imagined that there was a getSession(), because I saw getRequest
and getResponse and getServletContext() aka 'application'. my bad. The
code is now:
session = ((ViewContext)obj).getRequest().getSession();
ctx = session.getServletContext();
But how about that? a getSession() method on ViewContext. It can return
null if no valid session (it would never create one).
There is a filter in place to prevent people without sessions from
getting to the VVS, so sessions and cid in that session are 'guaranteed'
by other code. I shouldn't need to look for them elsewhere, and in fact,
don't want to. That's why I avoided vc.getAttribute(). (I don't want
people to be able to request: http://foo.com/index.vm?cid=777 and then
get someone else's data.)
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Best Practice for toolbox
Posted by Nathan Bubna <na...@esha.com>.
Mike Curwen said:
> DAO? We don't need no stinkin' DAO. ;)
>
> Well... I've taken this snip from:
> http://jakarta.apache.org/velocity/tools/view/
>
> that says:
> "The scope that you set for your tool will determine both its
> lifecycle and, if it implements the ViewTool interface, then
> the scope will also determine what data is passed to the
> init(Object) method"
>
> So I've so far got something like (which is horrible, I know!):
>
> public class ClientView extends HashMap implements ViewTool {
>
> public void init(Object obj) {
>
> ServletContext ctx = null;
> HttpSession session = null;
>
> String ds_string = null;
> String cid = null;
>
>
> if (obj instanceof ViewContext) {
> session = ((ViewContext)obj).getSession();
> ctx = session.getServetContext();
>
> ds_string = ctx.getInitParameter("sys_datasource");
> cid = (String)session.getAttribute("cid");
> }
// simplified...
ViewContext vc = (ViewContext)obj;
String ds_string = vc.getServletContext().getInitParameter("sys_datasource");
String cid = (String)vc.getAttribute("cid");
...
> So now this class is 'highly' coupled to not only javax.sql, but
> javax.servlet. I'm not sure what else to do about the coupling to
> HttpSession. I **require** the session to retrieve my cid.
that's fine. ViewTools (i.e. view-layer tools) for webapps should not fear
interacting with javax.servlet class where necessary.
> As for the ServletContext and the javax.sql stuff,
> I could remove all that and use a DAO instead.
...
yeah, that might not hurt. :)
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
RE: Best Practice for toolbox
Posted by Mike Curwen <gb...@gb-im.com>.
DAO? We don't need no stinkin' DAO. ;)
Well... I've taken this snip from:
http://jakarta.apache.org/velocity/tools/view/
that says:
"The scope that you set for your tool will determine both its
lifecycle and, if it implements the ViewTool interface, then
the scope will also determine what data is passed to the
init(Object) method"
So I've so far got something like (which is horrible, I know!):
public class ClientView extends HashMap implements ViewTool {
public void init(Object obj) {
ServletContext ctx = null;
HttpSession session = null;
String ds_string = null;
String cid = null;
if (obj instanceof ViewContext) {
session = ((ViewContext)obj).getSession();
ctx = session.getServetContext();
ds_string = ctx.getInitParameter("sys_datasource");
cid = (String)session.getAttribute("cid");
}
if (ds_string == null || ds_string.length() ==0) {
ds_string = "jdbc/sysDB";
}
if (cid == null || cid.length() == 0) {
cid = "0";
}
try {
DataSource ds = Utils.getDataSource(ds_string);
Connection con = ds.getConnection();
Statement st = con.createStatement();
ResultSet rs = st.executeQuery("SELECT * FROM client
WHERE client_id=" + cid);
Utils.putNextRowInMap(rs, this);
con.close();
} catch (Exception e) {
logger.error(e, e);
}
}
}
So the 'Utils' class is a library I have to do common db stuff like
'getDataSource' and 'quickly stuff this resultset into a List of Maps,
or just the next row into a Map', etc, etc.
So now this class is 'highly' coupled to not only javax.sql, but
javax.servlet. I'm not sure what else to do about the coupling to
HttpSession. I **require** the session to retrieve my cid. As for the
ServletContext and the javax.sql stuff, I could remove all that and use
a DAO instead.
> -----Original Message-----
> From: Gregg Bolinger [mailto:gregg@javaranch.com]
> Sent: Wednesday, March 17, 2004 9:36 AM
> To: Velocity Users List
> Subject: Re: Best Practice for toolbox
>
>
> But how is the ClientView class getting the appropriate
> values from the
> database by doing this? Wouldn't the front controller pass
> the client
> ID on to some DOA that populates your ClientView with the
> data you need
> first? Or do I have no idea what your program is doing.
>
> Gregg Bolinger
>
>
> Mike Curwen wrote:
>
> >Hi all,
> >
> >I'm reading up on the velocity tools, and here's a snip from
> >http://jakarta.apache.org/velocity/tools/
> >
> >"Also included is a Toolbox Manager which can automatically make
> >'view tools' and data available to the templates. Any class with
> >public methods can be used as a tool in the template."
> >
> >The "and data" is what has sparked my imagination. I have a
> site that
> >does personalized pages. I'm porting it away from the old
> >velocityservlet, onto VVS. The site is fairly simple, and
> there's not a
> >huge amount of 'processing' involved by any sort of
> traditional "front
> >controller". The only thing the current controller does is examines
> >the unique id (in the session), and retrieves that user's
> personal info
> >from the database. It does this on every request.
> >
> >So I'm thinking... hey...
> ><tool>
> > <key>client</key>
> > <scope>session</scope>
> > <class>com.gbim.util.ClientView</class>
> ></tool>
> >
> >
> >That class is something I'm already using in my current
> system. And just
> >by happy co-incidence, it was programmed with several public
> methods of
> >use to me.
> >So now, all I have to do is say: $client.name. And look at what I
> >just did.. I changed how often the class is instantiated , simply by
> >using 'session' scope, rather than request.
> >
> >So esentially, I can completely eliminate my front controller! Just
> >call any of my velocity pages directly, and the toolbox will
> populate my
> >client object the one time per session. It's declaritive
> programming!
> >
> >Should I be scared? Is this a 'best practice' use ? Something deep
> >inside is scared of it being this easy! ;)
> >
> >
> >-------------------------------------------
> >Mike Curwen 204-885-7733
> >Intermediate Programmer www.gb-im.com
> >-------------------------------------------
> > ____ ____ ___ __ __
> > / ___| | __ ) |_ _| | \/ |
> >| | _ | _ \ _____ | | | |\/| |
> >| |_| | | |_) | |_____| | | | | | |
> > \____| |____/ |___| |_| |_|
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail:
> velocity-user-help@jakarta.apache.org
> >
> >
> >
> >
> >
> >---
> >avast! Antivirus: Inbound message clean.
> >Virus Database (VPS): 0403-11, 03/16/2004
> >Tested on: 3/17/2004 9:19:42 AM
> >avast! is copyright (c) 2000-2003 ALWIL Software.
> >http://www.avast.com
> >
> >
> >
> >
> >
> >
>
> --
> Gregg Bolinger
> My Weblog <http://radio.javaranch.com/channel/gthought>
>
>
> ---
> avast! Antivirus: Outbound message clean.
> Virus Database (VPS): 0403-11, 03/16/2004
> Tested on: 3/17/2004 9:35:40 AM
> avast! is copyright (c) 2000-2003 ALWIL Software.
> http://www.avast.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Best Practice for toolbox
Posted by Gregg Bolinger <gr...@javaranch.com>.
But how is the ClientView class getting the appropriate values from the
database by doing this? Wouldn't the front controller pass the client
ID on to some DOA that populates your ClientView with the data you need
first? Or do I have no idea what your program is doing.
Gregg Bolinger
Mike Curwen wrote:
>Hi all,
>
>I'm reading up on the velocity tools, and here's a snip from
>http://jakarta.apache.org/velocity/tools/
>
>"Also included is a Toolbox Manager which can automatically make
>'view tools' and data available to the templates. Any class with
>public methods can be used as a tool in the template."
>
>The "and data" is what has sparked my imagination. I have a site that
>does personalized pages. I'm porting it away from the old
>velocityservlet, onto VVS. The site is fairly simple, and there's not a
>huge amount of 'processing' involved by any sort of traditional "front
>controller". The only thing the current controller does is examines the
>unique id (in the session), and retrieves that user's personal info from
>the database. It does this on every request.
>
>So I'm thinking... hey...
><tool>
> <key>client</key>
> <scope>session</scope>
> <class>com.gbim.util.ClientView</class>
></tool>
>
>
>That class is something I'm already using in my current system. And just
>by happy co-incidence, it was programmed with several public methods of
>use to me.
>So now, all I have to do is say: $client.name. And look at what I
>just did.. I changed how often the class is instantiated , simply by
>using 'session' scope, rather than request.
>
>So esentially, I can completely eliminate my front controller! Just
>call any of my velocity pages directly, and the toolbox will populate my
>client object the one time per session. It's declaritive programming!
>
>Should I be scared? Is this a 'best practice' use ? Something deep
>inside is scared of it being this easy! ;)
>
>
>-------------------------------------------
>Mike Curwen 204-885-7733
>Intermediate Programmer www.gb-im.com
>-------------------------------------------
> ____ ____ ___ __ __
> / ___| | __ ) |_ _| | \/ |
>| | _ | _ \ _____ | | | |\/| |
>| |_| | | |_) | |_____| | | | | | |
> \____| |____/ |___| |_| |_|
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
>
>
>
>---
>avast! Antivirus: Inbound message clean.
>Virus Database (VPS): 0403-11, 03/16/2004
>Tested on: 3/17/2004 9:19:42 AM
>avast! is copyright (c) 2000-2003 ALWIL Software.
>http://www.avast.com
>
>
>
>
>
>
--
Gregg Bolinger
My Weblog <http://radio.javaranch.com/channel/gthought>
---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0403-11, 03/16/2004
Tested on: 3/17/2004 9:35:40 AM
avast! is copyright (c) 2000-2003 ALWIL Software.
http://www.avast.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org