You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Ted Husted <hu...@apache.org> on 2001/12/01 18:03:16 UTC
RE: Velocity & Struts - redux
There is really only one object that the Struts framework puts into a
servlet context that would be a must-have for the VelocityContext, the
ActionForm bean.
There are other objects there, that could be used by the VelServlet
itself to create macros, but these would not need to be part of the
template writer's context.
The name of the ActionForm bean is encapsulated in the mapping passed in
the request. The mapping is stored under a static given by
Action.MAPPING_KEY. Once retrieved, you can can get the attribute name
(mapping.getAttribute()) for the name of the current form bean, and pass
that object to the VelocityContext.
There are other framework objects, like the MessageResources, but those
wouldn't be used by a Velocity developer directly, but through (I guess)
a macro. Likewise for the mappings. A macro might want to lookup the URI
for a logical forward, and use that to write a hyperlink tag, but that
is not something you would expect in a VelocityContext (as I understand
it).
Now, the Struts developers may be passing other objects in the request,
and there lies the rub. But, if you want to require that the Struts
developers using VelServlet pass everything they need as part of the
form bean, then you're done ;-)
Though, in practice, the ActionForm is only used for input forms. Most
pages can be rendered whatever JavaBeans the developer finds convenient.
It would be very keen if Velocity Templates could be drop-in
replacements for JSPs and other display mechanisms that rely on the
standard contexts. So, the question might be, how do we transparently
expose the standard servlet contexts to a Velocity template writer,
without binding the core of Velocity to servlets.
A strategy that JSP uses, and the Struts tag extensions follow, is to
search the contexts from nearest to farthest (unless told otherwise).
Could a subclass of the VelocityContext be constructed that would first
search its native context, then the servlet request context, then the
session context, and finally the application context, returning the
instance first found?
If so, then you might be able to simply pass to a ServletVelocityContext
the instant request context, and let it encapsulate which context
(Velocity, request, session, or application) actually returns the
property.
I apologize for ommitting Geir's original example application from my
resource page. Pure oversight on my part. (Must have been a busy news
week;-) I've got it up now, and will commit the link to the Struts
resource page in due course.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Velocity & Struts - redux
Posted by Donnie Hale <do...@haleonline.net>.
Ted,
I'm working on that kind of thing now. I've considered that it would be a
good idea to expose access to those things through an interface. Right now,
there's a terrible coupling that I just discovered from the forms, mappings,
actions, etc. to the servlet so they can get those things. The
"ResourceRepository" class I'm writing could implement that interface and
then those items could just be given a reference to the interface.
Unfortunately, no matter what, this means I'm going to have to make changes
in the action package that I was not expecting to have to make. :(
Thoughts?
Donnie
-----Original Message-----
From: Ted Husted [mailto:husted@apache.org]
Sent: Sunday, December 02, 2001 10:56 AM
To: Velocity Users List
Subject: Re: Velocity & Struts - redux
"Geir Magnusson Jr." wrote:
> The key thing about Velocity related to this issue is that with Velocity,
> you can access *any* public method of a Java class if the object is made
> available to the designer in the context.
>
> This is not limited to just JavaBean accessors (getters and setters), but
> anthing :
>
> $foo.getBar()
>
> $foo.woogie( "hellp", $array )
>
> $foo.getBar().barMethod( true )
>
> So the API of any of those objects in the scope contexts would be
accessible
> to the designer if they could get to those objects.
We could define a Struts Resources API easily enough. Here's what an
interface might look like.
public interface StrutsResources {
public void setResourceRequest(HttpServletRequest request);
public DataSource getDataSource();
public ActionErrors getActionErrors();
public Throwable getException();
public ActionFormBeans getActionFormBeans();
public ActionForwards getActionForwards();
public Locale getLocale();
public ActionMappings getActionMappings();
public MessageResources getMessageResouces();
public DiskMultipartRequestHandler getMultipartHandler();
public ActionServlet getActionServlet();
public Servlet getServlet();
public String getToken();
public ActionForm getActionForm(String name);
public ActionForward getActionForward(String name);
public ActionMapping getActionMapping(String name);
public ActionMapping getCurrentMapping();
public ActionForm getCurrentActionForm();
}
This would just be a wrapper that returned whatever from whatever
context. Most if it is just calling request.getAttribute($(*}_KEY).
-T.
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity & Struts - redux
Posted by Ted Husted <hu...@apache.org>.
"Geir Magnusson Jr." wrote:
> The key thing about Velocity related to this issue is that with Velocity,
> you can access *any* public method of a Java class if the object is made
> available to the designer in the context.
>
> This is not limited to just JavaBean accessors (getters and setters), but
> anthing :
>
> $foo.getBar()
>
> $foo.woogie( "hellp", $array )
>
> $foo.getBar().barMethod( true )
>
> So the API of any of those objects in the scope contexts would be accessible
> to the designer if they could get to those objects.
We could define a Struts Resources API easily enough. Here's what an
interface might look like.
public interface StrutsResources {
public void setResourceRequest(HttpServletRequest request);
public DataSource getDataSource();
public ActionErrors getActionErrors();
public Throwable getException();
public ActionFormBeans getActionFormBeans();
public ActionForwards getActionForwards();
public Locale getLocale();
public ActionMappings getActionMappings();
public MessageResources getMessageResouces();
public DiskMultipartRequestHandler getMultipartHandler();
public ActionServlet getActionServlet();
public Servlet getServlet();
public String getToken();
public ActionForm getActionForm(String name);
public ActionForward getActionForward(String name);
public ActionMapping getActionMapping(String name);
public ActionMapping getCurrentMapping();
public ActionForm getCurrentActionForm();
}
This would just be a wrapper that returned whatever from whatever
context. Most if it is just calling request.getAttribute($(*}_KEY).
-T.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity & Struts - redux
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 12/2/01 9:55 AM, "Ted Husted" <hu...@apache.org> wrote:
> "Geir Magnusson Jr." wrote:
>> There *is* no other way to use them other then through tag extensions.
>> I guess one approach would be to have any data that is universal (messages,
>> errors) be placed into the scopes with a nice name and nice API.
>
> We're discussing a JavaBean wrapper to encapsulate the shared resources,
> but that's not going to happen quickly.
>
> Each of these objects have their own API. The contexts are just used to
> make the objects available to other components in the application. In a
> JSP environment, each object's API is exposed to the developer through
> the tag extensions. Most developers are not aware of how these are
> stored, since either the tags access them or the object is provided
> through a method on the Action or the servlet.
>
> So, if I want a mapping for a particular path, I can just call
> servlet.findMapping(path), we don't go searching through the contexts.
> The servlet knows where it is.
>
> Likewise, to get the path for a particular Action, the developer doesn't
> have to access the contexts, the html:form tag knows where the mappings
> are, and then the uses the ActionMapping's API to get the path. The
> developer just provides a logical name, and the tag extension does the
> rest.
>
> The context keys are not cleanly documented, since it is really a deep
> implementation detail, not something that needs to be exposed in
> everyday development.
>
> I don't actually understand how Velocity works, but it sounded like any
> of the resources documented in the Action class (and exposed through tag
> extensions) should be made available through an easy-to-use macro or the
> equivalent. This then becomes the designer's API.
The key thing about Velocity related to this issue is that with Velocity,
you can access *any* public method of a Java class if the object is made
available to the designer in the context.
This is not limited to just JavaBean accessors (getters and setters), but
anthing :
$foo.getBar()
$foo.woogie( "hellp", $array )
$foo.getBar().barMethod( true )
So the API of any of those objects in the scope contexts would be accessible
to the designer if they could get to those objects.
>
>
>> Sure - and as beans, with nice names (basically anything that could be a
>> Java lexical identifier...) would be accessible from Velocity.
>
> The objects that Struts and developers place in the standard contexts
> for use on the presentation layer have typical Java names, like
> "itemForm". In the tag extensions, we refer to the various JavaBean
> properties using a dotted syntax like property="itemForm.lastName" to
> call the equivalent of itemForm.getLastName(). I imagine the same thing
> works in Velocity, but as $itemForm.lastName. So, we all on the same
> page here.
Yep
>
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel +1 716 737-3463
> -- http://www.husted.com/struts/
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity & Struts - redux
Posted by Ted Husted <hu...@apache.org>.
"Geir Magnusson Jr." wrote:
> There *is* no other way to use them other then through tag extensions.
> I guess one approach would be to have any data that is universal (messages,
> errors) be placed into the scopes with a nice name and nice API.
We're discussing a JavaBean wrapper to encapsulate the shared resources,
but that's not going to happen quickly.
Each of these objects have their own API. The contexts are just used to
make the objects available to other components in the application. In a
JSP environment, each object's API is exposed to the developer through
the tag extensions. Most developers are not aware of how these are
stored, since either the tags access them or the object is provided
through a method on the Action or the servlet.
So, if I want a mapping for a particular path, I can just call
servlet.findMapping(path), we don't go searching through the contexts.
The servlet knows where it is.
Likewise, to get the path for a particular Action, the developer doesn't
have to access the contexts, the html:form tag knows where the mappings
are, and then the uses the ActionMapping's API to get the path. The
developer just provides a logical name, and the tag extension does the
rest.
The context keys are not cleanly documented, since it is really a deep
implementation detail, not something that needs to be exposed in
everyday development.
I don't actually understand how Velocity works, but it sounded like any
of the resources documented in the Action class (and exposed through tag
extensions) should be made available through an easy-to-use macro or the
equivalent. This then becomes the designer's API.
> Sure - and as beans, with nice names (basically anything that could be a
> Java lexical identifier...) would be accessible from Velocity.
The objects that Struts and developers place in the standard contexts
for use on the presentation layer have typical Java names, like
"itemForm". In the tag extensions, we refer to the various JavaBean
properties using a dotted syntax like property="itemForm.lastName" to
call the equivalent of itemForm.getLastName(). I imagine the same thing
works in Velocity, but as $itemForm.lastName. So, we all on the same
page here.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity & Struts - redux
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 12/2/01 8:43 AM, "Ted Husted" <hu...@apache.org> wrote:
> "Geir Magnusson Jr." wrote:
>> It's not just about creating macros... Struts stuffs all sorts of things in
>> there, like the error stuff.
>
> The mappings, messages, and error queue are expected to be used by the
> tag extensions, or other presentation tools. Page designers are not
> expected to use these directly, but only through tag extensions, or the
> equivalent. Though, everything there would be available in the usual way
> if they did want to to use it directly. We just discourage that (as
> pennance for past excesses).
There *is* no other way to use them other then through tag extensions. Ok
scriptlets, but I think they are universally understood to be evil at this
point anyway :)
I guess one approach would be to have any data that is universal (messages,
errors) be placed into the scopes with a nice name and nice API.
Then both the tag extensions could use them, and Velocity and other
templating systems as well. That would be huge - Struts then doesn't give
up anything in support of it's biggest user base, the JSP-ers, but allows us
templating wierdo's access :)
>
> The only custom data that Struts puts into the context intended for a
> page designer to use directly, by reference through a tag extension or
> equivalent, is the form bean. Though, developers often provide other
> custom beans in the request as well.
Sure - and as beans, with nice names (basically anything that could be a
Java lexical identifier...) would be accessible from Velocity.
>> The problem I saw before was that stuff had really bizarre names, and it
>> wasn't clear where anything was put and why. Might have been a
>> documentation issue, but I am not sure.
>
> The context attribute names are maintained as static fields in the
> Action class.
>
> http://jakarta.apache.org/struts/api-1.0/org/apache/struts/action/Action.html
Cool beans :)
> They use a *_KEY suffix.
That might be ugly in a Velocity template, but would still work. :)
This is getting interesting.
> If there is anything specific I can clarify, please feel free to ask.
>
> -T.
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Be a giant. Take giant steps. Do giant things...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity & Struts - redux
Posted by Ted Husted <hu...@apache.org>.
"Geir Magnusson Jr." wrote:
> It's not just about creating macros... Struts stuffs all sorts of things in
> there, like the error stuff.
The mappings, messages, and error queue are expected to be used by the
tag extensions, or other presentation tools. Page designers are not
expected to use these directly, but only through tag extensions, or the
equivalent. Though, everything there would be available in the usual way
if they did want to to use it directly. We just discourage that (as
pennance for past excesses).
The only custom data that Struts puts into the context intended for a
page designer to use directly, by reference through a tag extension or
equivalent, is the form bean. Though, developers often provide other
custom beans in the request as well.
> The problem I saw before was that stuff had really bizarre names, and it
> wasn't clear where anything was put and why. Might have been a
> documentation issue, but I am not sure.
The context attribute names are maintained as static fields in the
Action class.
http://jakarta.apache.org/struts/api-1.0/org/apache/struts/action/Action.html
They use a *_KEY suffix.
If there is anything specific I can clarify, please feel free to ask.
-T.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity & Struts - redux
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 12/1/01 12:03 PM, "Ted Husted" <hu...@apache.org> wrote:
> There is really only one object that the Struts framework puts into a
> servlet context that would be a must-have for the VelocityContext, the
> ActionForm bean.
>
> There are other objects there, that could be used by the VelServlet
> itself to create macros, but these would not need to be part of the
> template writer's context.
It's not just about creating macros... Struts stuffs all sorts of things in
there, like the error stuff.
>
> The name of the ActionForm bean is encapsulated in the mapping passed in
> the request. The mapping is stored under a static given by
> Action.MAPPING_KEY. Once retrieved, you can can get the attribute name
> (mapping.getAttribute()) for the name of the current form bean, and pass
> that object to the VelocityContext.
>
> There are other framework objects, like the MessageResources, but those
> wouldn't be used by a Velocity developer directly, but through (I guess)
> a macro.
Wait. Why not? It's perfectly valid for a template author to use them
directly. I made this work in the proof of concept (POC) example and it
worked fine.
> Likewise for the mappings. A macro might want to lookup the URI
> for a logical forward, and use that to write a hyperlink tag, but that
> is not something you would expect in a VelocityContext (as I understand
> it).
Anything and everyhing should be available to the template. That is one of
the really nice things about Velocity - you aren't constrained to use
artificial framework-y data types...
So a user should be able to just access stuff.
> Now, the Struts developers may be passing other objects in the request,
> and there lies the rub. But, if you want to require that the Struts
> developers using VelServlet pass everything they need as part of the
> form bean, then you're done ;-)
>
No, I was just thinking that some sort of pattern could be converged to...
The problem I had when making the POC was that I was constantly having to
dump the scopes and see what was in there.
> Though, in practice, the ActionForm is only used for input forms. Most
> pages can be rendered whatever JavaBeans the developer finds convenient.
>
> It would be very keen if Velocity Templates could be drop-in
> replacements for JSPs and other display mechanisms that rely on the
> standard contexts. So, the question might be, how do we transparently
> expose the standard servlet contexts to a Velocity template writer,
> without binding the core of Velocity to servlets.
>
> A strategy that JSP uses, and the Struts tag extensions follow, is to
> search the contexts from nearest to farthest (unless told otherwise).
> Could a subclass of the VelocityContext be constructed that would first
> search its native context, then the servlet request context, then the
> session context, and finally the application context, returning the
> instance first found?
I did this a while ago for the taglib I wrote that lets you use Velocity in
JSP
http://jakarta.apache.org/velocity/veltag.html
The problem I saw before was that stuff had really bizarre names, and it
wasn't clear where anything was put and why. Might have been a
documentation issue, but I am not sure.
>
> If so, then you might be able to simply pass to a ServletVelocityContext
> the instant request context, and let it encapsulate which context
> (Velocity, request, session, or application) actually returns the
> property.
>
> I apologize for ommitting Geir's original example application from my
> resource page. Pure oversight on my part. (Must have been a busy news
> week;-) I've got it up now, and will commit the link to the Struts
> resource page in due course.
Oooh... I better fix it up then :)
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel +1 716 737-3463
> -- http://www.husted.com/struts/
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity & Struts - redux
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 12/1/01 5:23 PM, "Paulo Gaspar" <pa...@krankikom.de> wrote:
> I do not remember enough from JSP (I was converted very soon) but,
> again, it sounds like you might be pointing in the right direction.
>
> Maybe Geir knows better. He was fighting with the taglib stuff more
> recently.
When I ran across this issue in the tag library, I just extended the Context
to be a flail-o-matic, and search 'upwards' in scope to find something.
(There was a switch to turn this off...)
I think that was a good approach to start, and I can't think of anything
else...
What would be nice is a description of what objects are placed in the
session and request scopes, and under what name...
>
>
> Have fun,
> Paulo Gaspar
>
>> -----Original Message-----
>> From: Ted Husted [mailto:husted@apache.org]
>> Sent: Saturday, December 01, 2001 8:27 PM
>>
>> Hey, I see that Velocity already supports chained contexts.
>>
>> So could a session facade be chained to a request facade chained to a
>> base Velocity context?
>>
>> Then neither Struts (or another system using the session and request
>> contexts) nor Velocity would need to change, and everyone could just do
>> what they do best.
>>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Velocity & Struts - redux
Posted by Paulo Gaspar <pa...@krankikom.de>.
I do not remember enough from JSP (I was converted very soon) but,
again, it sounds like you might be pointing in the right direction.
Maybe Geir knows better. He was fighting with the taglib stuff more
recently.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: Saturday, December 01, 2001 8:27 PM
>
> Hey, I see that Velocity already supports chained contexts.
>
> So could a session facade be chained to a request facade chained to a
> base Velocity context?
>
> Then neither Struts (or another system using the session and request
> contexts) nor Velocity would need to change, and everyone could just do
> what they do best.
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity & Struts - redux
Posted by Ted Husted <hu...@apache.org>.
Hey, I see that Velocity already supports chained contexts.
So could a session facade be chained to a request facade chained to a
base Velocity context?
Then neither Struts (or another system using the session and request
contexts) nor Velocity would need to change, and everyone could just do
what they do best.
Paulo Gaspar wrote:
>
> > Now, the Struts developers may be passing other objects in the request,
> > and there lies the rub. But, if you want to require that the Struts
> > developers using VelServlet pass everything they need as part of the
> > form bean, then you're done ;-)
>
> I talked about passing a facade to whatever is the object behind the form
> tag from Struts.
>
> Which mechanism builds such facade and passes it to the Velocity context
> is something to find out. I just do NOT understand why Velocity has to
> change.
>
> (Would it be good to make Velocity more JSP-like? Argh! Even the JSP guys
> are starting to want using Velocity!)
>
> Anyway, I think the mechanism you suggest is the direction to go: let an
> intermediate object do the job. Convenience facades as the above
> mentioned wrap and replace the original object as part of the discovery
> process you describe.
>
> A map from JSP-object-clas => Facade-class or Facade-factory-class would
> make the thing flexible and extensible.
>
> Have fun,
> Paulo Gaspar
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Velocity & Struts - redux
Posted by Paulo Gaspar <pa...@krankikom.de>.
> Now, the Struts developers may be passing other objects in the request,
> and there lies the rub. But, if you want to require that the Struts
> developers using VelServlet pass everything they need as part of the
> form bean, then you're done ;-)
I talked about passing a facade to whatever is the object behind the form
tag from Struts.
Which mechanism builds such facade and passes it to the Velocity context
is something to find out. I just do NOT understand why Velocity has to
change.
(Would it be good to make Velocity more JSP-like? Argh! Even the JSP guys
are starting to want using Velocity!)
Anyway, I think the mechanism you suggest is the direction to go: let an
intermediate object do the job. Convenience facades as the above
mentioned wrap and replace the original object as part of the discovery
process you describe.
A map from JSP-object-clas => Facade-class or Facade-factory-class would
make the thing flexible and extensible.
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: Saturday, December 01, 2001 6:03 PM
> To: velocity-user@jakarta.apache.org
> Subject: RE: Velocity & Struts - redux
>
>
> There is really only one object that the Struts framework puts into a
> servlet context that would be a must-have for the VelocityContext, the
> ActionForm bean.
>
> There are other objects there, that could be used by the VelServlet
> itself to create macros, but these would not need to be part of the
> template writer's context.
>
> The name of the ActionForm bean is encapsulated in the mapping passed in
> the request. The mapping is stored under a static given by
> Action.MAPPING_KEY. Once retrieved, you can can get the attribute name
> (mapping.getAttribute()) for the name of the current form bean, and pass
> that object to the VelocityContext.
>
> There are other framework objects, like the MessageResources, but those
> wouldn't be used by a Velocity developer directly, but through (I guess)
> a macro. Likewise for the mappings. A macro might want to lookup the URI
> for a logical forward, and use that to write a hyperlink tag, but that
> is not something you would expect in a VelocityContext (as I understand
> it).
>
> Now, the Struts developers may be passing other objects in the request,
> and there lies the rub. But, if you want to require that the Struts
> developers using VelServlet pass everything they need as part of the
> form bean, then you're done ;-)
>
> Though, in practice, the ActionForm is only used for input forms. Most
> pages can be rendered whatever JavaBeans the developer finds convenient.
>
> It would be very keen if Velocity Templates could be drop-in
> replacements for JSPs and other display mechanisms that rely on the
> standard contexts. So, the question might be, how do we transparently
> expose the standard servlet contexts to a Velocity template writer,
> without binding the core of Velocity to servlets.
>
> A strategy that JSP uses, and the Struts tag extensions follow, is to
> search the contexts from nearest to farthest (unless told otherwise).
> Could a subclass of the VelocityContext be constructed that would first
> search its native context, then the servlet request context, then the
> session context, and finally the application context, returning the
> instance first found?
>
> If so, then you might be able to simply pass to a ServletVelocityContext
> the instant request context, and let it encapsulate which context
> (Velocity, request, session, or application) actually returns the
> property.
>
> I apologize for ommitting Geir's original example application from my
> resource page. Pure oversight on my part. (Must have been a busy news
> week;-) I've got it up now, and will commit the link to the Struts
> resource page in due course.
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel +1 716 737-3463
> -- http://www.husted.com/struts/
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>