You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Donnie Hale <do...@haleonline.net> on 2001/11/21 03:10:47 UTC
Velocity & Struts - redux
Folks,
In the archives, I've seen some on-again, off-again threads regarding using
Struts w/ Velocity. I downloaded Geir's example from April. Unfortunately,
it doesn't seem that the org.apache.velocity.struts.VelServlet source code
is in that .zip file (the .class file is in the
WEB-INF/lib/struts-velocity-...jar> file).
I'd sort of like to get a look at that to see if it's doing what I'd expect
it would need to be doing for the integration to work as I think it
should/would.
Is there any chance I can get that? Has it ever been put in CVS? (Not much
of a CVS expert - thus the question...)
Thanks,
Donnie
--
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>.
Away for a day - sorry for the delay in responding. See below:
Donnie
-----Original Message-----
From: Gabriel Sidler [mailto:sidler@teamup.ch]
Sent: Monday, November 26, 2001 12:29 AM
To: Velocity Users List
Subject: Re: Velocity & Struts - redux
Donnie,
Donnie Hale wrote:
[...]
> Struts uses contexts (request/session/servlet) ***very extensively*** to
> store info (too extensively, IMO). One of the reasons why is that there's
an
> assumption that view rendering will always occur after a forward/redirect
> and thus those are the only hooks to get back at the info the view needs
to
> do its job. If view rendering happened immediately after processing the
> action, much of the need for using that stuff would go away. I see the
need
> for session usage as one progresses through pages that make up a whole
> scenario - that's unavoidable. But using the contexts as a server-side
state
> repository for implicit parameter passing goes against their intention,
IMO.
>>>From my point of view, the primary purpose of the different contexts in
Struts (request, session, servlet) is not to serve as a state repository,
but to ensure a certain scope or service live of my objects. I don't think
that this is something we could or should avoid.<<
Take another look at all the stuff shoved in those contexts that's unrelated
to the handling of the request in question.
> >>That is now how it see it. In Struts, the form bean is only representing
> the request parameters. In my unterstanding the context should be
everything
> that you have available when executing the service() method of class
> HttpServlet.
> This includes all members of class HttpServlet as well as instances
> of HttpRequest and HttpRespose. The Struts form bean can be accessed from
> the HttpRequest instance.<<
>
> You're correct. I just saw some old Struts list messages that better
> explained the design goals for ActionForms. My question now is, "why isn't
> the design for supplying info to the view after processing the ActionForm
> more formalized?"
>>As a developer I choose the classes and I choose the appropriate context,
depending on the service life of my objects. This constitutes the view API.
So far I never felt a need for a more formalized interface between C and V.
What is in your mind?<<
Maybe it's app-specific, but something like an interface that the view
expects (independent of Action, ActionForm, etc.) and which is set into the
request when the Action completes. So that it's not always some seemingly
random, could-be-anything set of object / objects. And also to provide a
single point-of-access to all the objects that the view may need. I could be
off base here...
>>Several people have proposed/discussed the use of a Velocity Context that
is filled within the Action classes. However, such a approach would intro-
duce a dependency between the C and V and should really be avoided. My
action
classes should be independent of Velocity. I'd like to be able to switch
anytime between Velocity and JSP as a view technologie.<<
Well a VelocityContext has to be created at some point. The question is,
"Where?". I'd like the creation of that context to be abstracted as much as
possible, so wherever it's filled, it has to have enough info to do it.
>>One more thing I'd like to add here: Several people have mentioned
recently
that Struts is very much JSP-oriented. That is not true. The core of the
Struts framework is beautifully independent of JSP! That makes it so easy
to integrate Velocity. I did a simple prototype during a weekend, including
learning Struts.
Only view technologies like the htm:form tag lib or the Struts form
validation
framework are naturally JSP-centric.
However, Struts is very much Servlet API oriented.<<
In terms of its implementation, that's true. But in terms of the expected
target view technology, it's not. And judging by the response of the folks
on struts-dev, I think they'd agree. It's not precluding other views, it's
just not real friendly to them.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity & Struts - redux
Posted by Gabriel Sidler <si...@teamup.ch>.
Donnie,
Donnie Hale wrote:
[...]
> Struts uses contexts (request/session/servlet) ***very extensively*** to
> store info (too extensively, IMO). One of the reasons why is that there's an
> assumption that view rendering will always occur after a forward/redirect
> and thus those are the only hooks to get back at the info the view needs to
> do its job. If view rendering happened immediately after processing the
> action, much of the need for using that stuff would go away. I see the need
> for session usage as one progresses through pages that make up a whole
> scenario - that's unavoidable. But using the contexts as a server-side state
> repository for implicit parameter passing goes against their intention, IMO.
>From my point of view, the primary purpose of the different contexts in
Struts (request, session, servlet) is not to serve as a state repository,
but to ensure a certain scope or service live of my objects. I don't think
that this is something we could or should avoid.
> >>That is now how it see it. In Struts, the form bean is only representing
> the request parameters. In my unterstanding the context should be everything
> that you have available when executing the service() method of class
> HttpServlet.
> This includes all members of class HttpServlet as well as instances
> of HttpRequest and HttpRespose. The Struts form bean can be accessed from
> the HttpRequest instance.<<
>
> You're correct. I just saw some old Struts list messages that better
> explained the design goals for ActionForms. My question now is, "why isn't
> the design for supplying info to the view after processing the ActionForm
> more formalized?"
As a developer I choose the classes and I choose the appropriate context,
depending on the service life of my objects. This constitutes the view API.
So far I never felt a need for a more formalized interface between C and V.
What is in your mind?
> >>I my view the forwarding in Struts is an elegant concept to introduce a
> configurable indirection between the C of MVC (Action classes) and the
> V of MVC(JSP pages). I would definately stick with this concept. Why would
> you want to get rid of forwarding?<<
>
> See above, for one thing. I see forwarding as only required because JSPs
> *must* run in their own servlet; so there's no alternative to doing that.
> But in an architecture that doesn't presume forwarding, you can still have
> the decoupling of C and V.
I see forwarding mainly as a configurable indirection between C and V and
as such I find it very useful.
Why would you want to get rid of forwarding?
Several people have proposed/discussed the use of a Velocity Context that
is filled within the Action classes. However, such a approach would intro-
duce a dependency between the C and V and should really be avoided. My action
classes should be independent of Velocity. I'd like to be able to switch
anytime between Velocity and JSP as a view technologie.
One more thing I'd like to add here: Several people have mentioned recently
that Struts is very much JSP-oriented. That is not true. The core of the
Struts framework is beautifully independent of JSP! That makes it so easy
to integrate Velocity. I did a simple prototype during a weekend, including
learning Struts.
Only view technologies like the htm:form tag lib or the Struts form validation
framework are naturally JSP-centric.
However, Struts is very much Servlet API oriented.
[...]
> I do agree that a structured context is better. My first issue more lies
> with shoving everything that Struts shoves in the contexts in the
> VelocityContext. For example, Struts puts datasources in the ServletContext.
> A view will never need those (I hope :). My second issue has to do with one
> of Velocity's core premises, and that is that a view-specific "API" will be
> communicated to the view developer. I don't think it's good to ask the view
> developer to have to navigate the servlet API / contexts to get the view
> info they need. In the normal case, I'd think it better to be able to fill
> the VelocityContext as it would be without Struts. That doesn't necessarily
> mean the appropriate things from the servlet contexts couldn't also be
> available; just that they wouldn't be the primary source of view info.
>
> To support that, we likely have to make the "VelServlet" fancier to allow
> the Java developers to fill the VelocityContext with the expected view
> "API". I'll go back to something I hinted at in my previous message. Let's
> say we recommend a design approach for Actions that will be part of a
> Velocity-based application that they put something in the request that can
> be retrieved when "VelServlet" runs. Right now, I'm not sure if this could
> be via a single, well-known name or if the name would need to become a
> parameter somehow (I'd love to avoid more config files if possible - another
> design constraint :). Now, when VelServlet runs, it retrieves that item from
> the request. If the object implements a "ContextPopulator" interface,
> VelServlet invokes it. Presumably, the object would have all the info it
> needs to fill the VelocityContext without accessing the various servlet
> contexts. If it doesn't implement that interface, VelServlet can stuff it in
> the VelocityContext using that name so that it's more directly available
> than it would be going through the request.
Such an approach would introduce a dependency between the C and V. Right now
Struts uses the Servlet API as an interface between C and V. This is standardized,
well known, widely used. There are certainly different ways to do it. But why?
[...]
> One other question came to mind: Is it important that the solution allow for
> direct requests of .vm files? If so, how should that work?
Yes, I think it should be possible to access .vm files directly. If Velocity
is integrated as a servlet, it is easy. Simply define a mapping between the
.vm extention and the VelocityServlet in the Tomcat configuration. The Servlet
API provides the vm template access to the different contexts even in this
scenario.
Gabe
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity & Struts - redux
Posted by Rickard Oberg <ri...@xpedio.com>.
Tim Colson wrote:
> The Struts Camp is driving with only JSP's in mind; consequently, updates
> and add-ons are JSP centric (ex. Dave Winterfeldt's excellent form Validator
> package extends ActionForm, and provides taglibs which create dynamic client
> side javascript.)
That's bad, but it's a (somewhat) inherent feature of Struts. To the
contrary, the WebWork framework (which I'm heading) tries to stay as
view-agnostic as possible (we have JSP, Velcotity, stand-alone client,
and XSLT support right now), and in order to do so we try to factor out
taglib functionality into beans that can be used by either environment.
It's not perfect yet (some functionality is duplicated in
taglib/Velocity beans), but it's definitely the direction we're striving
for.
> Up until now, Geir has been the only voice on the Struts list to suggest
> Velocity as a JSP alternative. Perhaps more of us should subscribe to the
> struts-user list and say, "Hey guys, great work on this Struts stuff... but
> can we help out to decouple the view and build support out of the box for
> more options like Velocity?" :-)
IMHO your efforts would be better spent on the WebWork lists. There are
already people there using Velocity, and as above, WebWork really makes
an effort to stay as view agnostic as possible.
> I believe that a Template Designer should expect $thingy to simply get a
> value - from wherever it lives. This can be accomplished by the Developer
> flattening the scopes into one context which is simple, effective, and what
> Geir did. ;-)
Precisely, which is exactly what WebWork does. :-)
> FYI - this complexity of naming scopes seeping into the View makes me think
> that if Struts code was less JSP centric, population of a context wouldn't
> be so mangled.
In WebWork all $names are resolved against the action that was executed
prior to the view (e.g. if the action has a getResult() method, then
$result is valid in the template). So, if you want to access request
parameters (not so common) you'd use the $req object (the request) to
get to it. This is definitely not the common way to do it though. The
action usually provides all the data that is needed.
> Developers populate a 'context' hash in the Struts Action, then they stick
> that hash into the request, and this the only object that the VelServlet
> uses for the Velocity Context. VelServlet would copy all keys from this
> known-good object "VelocityContext" into a real Velocity context object.
WebWork uses a ValueStack which is put onto the request after the action
has been executed. the WebWork subclass of VelocityServlet then uses a
context that first delegates to this ValueStack before trying the normal
Velocity context (so that you can still use #set in your template). This
stack works regardless of whether JSP or XSLT or Velocity is used (i.e.
the controller servlet really really doesn't care what the view
technology is).
Here's an example of a calendar renderer. The code:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/webwork/webwork/src/main/webwork/action/test/MonthList.java?rev=1.3&content-type=text/vnd.viewcvs-markup
The Velocity view:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/webwork/webwork/src/main/webwork/action/test/MonthList.java?rev=1.3&content-type=text/vnd.viewcvs-markup
The JSP view:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/webwork/webwork/src/resources/web/monthlist.jsp?rev=1.7&content-type=text/vnd.viewcvs-markup
In this particular case there is no view configuration mapping, i.e. the
JSP/template reference and execute the action directly in a Model-1 way,
but it would be entirely possible to do it in a Model-2 way instead.
WebWork supports both Model-1 and Model-2, since they both have advantages.
> Developers would handle scopes and objects normally - only placing those
> items they feel are needed into the context.
In WebWork that is done by adding get* methods to your actions. See
above example. Doesn't get much simpler.
> They could stick the current
> ActionForm object in there. Context Tools. Even the wrapped Messages object.
> Errors objects could be stuck in there from the form.validate() methods.
In the doValidate() method of WebWork actions you typically add error
messages to the result by calling addError() or addErrorMessage(),
depending on whether it's a form error or a form field error. These are
then access by the view by doing either:
#foreach ($error in $errors)
$error<br>
#end
or (in JSP):
<webwork:iterator value="errors">
<webwork:property/><br>
</webwork:iterator>
> This enables a Developer to put whatever is _needed_ into the context. If
> they feel that the entire request object is truly necessary, they can shove
> it in there. And it allows Designers easy access to whatever is in there
> without having to chant $request.get("user").FirstName - just
> $user.FirstName would do.
Yup. Couldn't agree more. You're describing WebWork :-)
> Questions:
> 1) Is it really that easy - what am I missing?
Super-simple. Been there, done that. Use WebWork :-)
> 2) How performance ugly is it to populate a hash, and then use it to
> populate the Velocity context?
Not at all, if you implement the context to access the hash directly,
except in WebWork the "hash" are the get-methods of your action.
> 3) Is there any reason not to simply populate a real Velocity Context
> directly in the Struts Action and pass that to the VelServlet?
Yes, then the action would be tightly bound to velocity.
As above, using WebWork you can avoid view-specific bindings and be able
to reuse your code for whatever view technology makes you tick. Or
change your mind after a year, and your code still works. Or use it with
several, for example both Velocity and a stand-alone client using Swing.
Sorry for the blatant WebWork plug here, but it seems unnecessary to
have you waste time on things that are already there, tested and working.
Da link:
http://sourceforge.net/projects/webwork
Download RC3 and take a look at the examples. If you have any questions
on WebWork, check the mailing list.
/Rickard
--
Rickard Öberg
--
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>.
Tim,
I've been making comments on struts-dev to this effect recently. I think
there's some philosophical agreement, but Ted Husted said it didn't "scratch
where he itched right now". As I've said, I want all those little magical
corner of Struts w/o JSP.
Donnie
-----Original Message-----
From: Tim Colson [mailto:tcolson@cisco.com]
Sent: Sunday, November 25, 2001 2:09 AM
To: Velocity Users List
Subject: RE: Velocity & Struts - redux
Donnie -
> >>OK. I would favor an approach that does not touch the Struts source. Not
> even extending it. I believe this is possible. This will make it much
> easier to keep up with future development of Struts.<<
As I learn more about Struts, I'm starting to think modification of the
Struts source may be a good long term idea for easier maintenance. Let me
explain:
The Struts Camp is driving with only JSP's in mind; consequently, updates
and add-ons are JSP centric (ex. Dave Winterfeldt's excellent form Validator
package extends ActionForm, and provides taglibs which create dynamic client
side javascript.)
I believe this JSP bias will make a Struts-Velocity bridge hard to maintain
(ex. How will I use a Velocity only view and still gain the advantages of
the Validator package without additional work to the Glue/Bridge? BTW, this
pkg will be part of Struts 1.1 real soon now.)
Up until now, Geir has been the only voice on the Struts list to suggest
Velocity as a JSP alternative. Perhaps more of us should subscribe to the
struts-user list and say, "Hey guys, great work on this Struts stuff... but
can we help out to decouple the view and build support out of the box for
more options like Velocity?" :-)
(In the shorter term, it still might be more persuasive if we can show
Velocity and Struts playing together nicely. Expanding on Geirs remarkable
re-work of the Struts example app, and/or Ted Husted's struts-simple.war on
husted.com, to show ease of use of Velocity versus JSP might be helpful
too.)
---
>>> To [Gabe] sessions are an important concept of a Web application....
>>> [Gabe] don't find this very managable. And it is different
>>> from anything known to developers (JSP, Servlet API).
>> [Donnie] do agree that a structured context is better.
There's been discussion before on this. I think Geir had it mostly right
saying that scopes are important but are the province of the Servlet
DEVELOPER. They are of little use and likely confusion for the Template
DESIGNER.
I believe that a Template Designer should expect $thingy to simply get a
value - from wherever it lives. This can be accomplished by the Developer
flattening the scopes into one context which is simple, effective, and what
Geir did. ;-)
One potential drawback to an AUTOMATED* flattening approach is possible
namespace overlap/collisions. A Developer could write an Application scoped
object $thingy, and s/he wouldn't expect it to clash with a request scoped
$thingy.
(*Presumably if the Developer were creating the context manually, they would
be smart enough to populate $thingy with Req.thing, or Session.thing.)
So assuming $thingy lives in potentialy all scopes, perhaps the following
could happen:
Populate context in the order request->session->app, the first time an
object is seen, it gets stuck into $thingy. But also prepend a scope
qualifier ex. $request.preference, $session.preference or $app.preference
for access directly if needed.
FYI - this complexity of naming scopes seeping into the View makes me think
that if Struts code was less JSP centric, population of a context wouldn't
be so mangled.
Donnie wrote:
> Now, when VelServlet runs, it retrieves that item from
> the request. If the object implements a "ContextPopulator" interface,
> VelServlet invokes it. Presumably, the object would have all the info it
> needs to fill the VelocityContext without accessing the various servlet
> contexts. If it doesn't implement that interface, VelServlet can
> stuff it in the VelocityContext using that name so that
> it's more directly available
> than it would be going through the request.
(I'm going to ramble here a bit... please don't bite. )
Hmmm...howabout this simpler variation on that theme:
Developers populate a 'context' hash in the Struts Action, then they stick
that hash into the request, and this the only object that the VelServlet
uses for the Velocity Context. VelServlet would copy all keys from this
known-good object "VelocityContext" into a real Velocity context object.
Developers would handle scopes and objects normally - only placing those
items they feel are needed into the context. They could stick the current
ActionForm object in there. Context Tools. Even the wrapped Messages object.
Errors objects could be stuck in there from the form.validate() methods.
This enables a Developer to put whatever is _needed_ into the context. If
they feel that the entire request object is truly necessary, they can shove
it in there. And it allows Designers easy access to whatever is in there
without having to chant $request.get("user").FirstName - just
$user.FirstName would do.
If there is an Application scoped 'preference' as well as a request and
session pref... they can put in whichever is pertinent, using whatever
naming convention suites them.
Questions:
1) Is it really that easy - what am I missing?
2) How performance ugly is it to populate a hash, and then use it to
populate the Velocity context?
3) Is there any reason not to simply populate a real Velocity Context
directly in the Struts Action and pass that to the VelServlet?
--
> Is it important that the solution allow for
> direct requests of .vm files? If so, how should that work?
I think so - need that for example during form based login (login.jsp).
However, I'd expect that for this type of request, it'd be no different
really. The context would simply be a lot emptier. ;-)
Other bits:
Templates/Layouts - to me this is the biggest ugliness of Struts that needs
to be addressed. Right now, we're using the TEMPLATE taglib in one JSP which
sets some items including the main body in a second JSP and then calls up
one of the global page layout JSPs, which inserts the items. There has been
a lot of recent discussion on this topic lately...but it was unclear to me
if something definitive came out of it.
FYI - Using the Struts template: taglib, the first JSP would include the
correct body JSP and assign it to the generic label 'BODY'... and then the
template tag pulls in the 'layout.jsp' which inserts 'BODY' wherever it
goes.
I'd like to see the VelServlet handle this in some way without the need for
that first page... perhaps by passing in 'Velocity.LAYOUT' and one or more
'Velocity.TEMPLATE' params in the context, VelServlet could dynamically
merge template bits into the layout.
HTML Taglibs replaced with Macros would be a good idea. (right now, I don't
like the custom html:foo taglibs because they hide the 'real HTML' inside
java taglib code...icky, a global macro would be easier to see what's
happening under the covers by the Designer)
Cheers,
Timo
--
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: My $0.02 to Velocity usage (was: Velocity & Struts - redux )
Posted by Tim Colson <tc...@cisco.com>.
Rickard -
> Sorry for being annoying, but IMHO you would be wasting a serious amount
> of time, unless there is something fundamentally wrong with WebWork
Not annoying - but you must admit there is a lot of good support from folks
like Craig and Ted for Struts (and the 42 million folks who post daily to
the Struts-user mailing list <grin>).
And there are certainly some good ideas in there (you've borrowed a
few)...it's mostly the JSP stuff that makes my skin itch.
Therefore, I feel it is reasonable to 'supplement' Struts with Velocity.
:-)
BTW - I have looked at WebWork on a few occassions, and will continue to do
so as it matures. However, the RC3 status and scant documentation make it a
tough sell to my team for consideration.
> you want to do it over (which was the case when Jon told me "been there
> done that" when I wrote WebWork instead of using Turbine).
Hah hah...I recall those threads. :-) That reminds me, has Jon unsub'd from
the list? Or is he simply lurking and ultra-super-busy with Scarab?
Cheers,
Timo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: My $0.02 to Velocity usage (was: Velocity & Struts - redux )
Posted by Konstantin Priblouda <kp...@yahoo.com>.
>
> Having shown WebWork to my project managers: no I
> wouldn't be able to
> sell Struts to them either ;-)
gone to look at WebWork :)
regards,
=====
Konstantin Priblouda ( ko5tik ) Freelance Software developer
< http://www.pribluda.de > < play java games -> http://www.yook.de >
< render charts online -> http://www.pribluda.de/povray/ >
__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: My $0.02 to Velocity usage (was: Velocity & Struts - redux )
Posted by Rickard Öberg <ri...@xpedio.com>.
Konstantin Priblouda wrote:
>>Yes, loads. So, instead of putting them all in
>>there, why not make it
>>possible to define in the template what you need,
>>and just put *that*
>>there. WebWork allows this by adding a #bean macro
>>(to instantiate a
>>JavaBean) and a #action macro (to allow things that
>>can execute to be
>>accessed).
>>
>
> Even read YMTD? Ugly, scary and sort of thing
> velocity is trying to avoid :)
What does the YMTD doc (which I have read) have to do with the above?
> What I like to achive is, good separation between
> java code ( to populate context ) and template
> ( say, between me, hacker, and those sleek types
> who are called wob designers and know nothing :) )
Agree.
> I also like it to be completely framework unaware:
> We speking just templating here. We do not know ( or
> bother ) about actions.
Sure. That's ok. Just don't use the #bean or #action macros and you'll
be fine.
> We have just a wiew ( velocity template ) and
> class[es] ( mapped as impicitly as possible ) which
> populates context for it
And WebWork allows just that. Make an action, have a bunch of
get-methods, done.
> To make velocity an JSP killer we need to made it
> usage as hassle-free as possible, and mapping actions
> to templates ( even if there is no action at all,
> like displaying list of some EJB's )
Displaying a list of EJB's *is* an action. Some actions are read/write,
and some are read-only. An action is simply a piece of code that gets
executed with a given set of parameters.
> requires some
> doctoring on conguguration files.
Yes, and both your code and templates will be much better off because of it.
> Template/Implicitely mapped class has advatage of
> clear separation between persentation code and data
> pulling logic ( and designers can not tweak in
> scriptlets... )
Again, this is what you get in WebWork.
> What I like to achieve is framework-blind templating
> with all the nice features from different templating
> systems ( velocity for templating, HTML:Mason
> for implicitly mapped code etc. )
With WebWork your templates can be as framework agnostic as you want
them to be. The additional WebWork macros can be ignored, and getting
things from the contetx is "business as usual" from a template point of
view.
>>http://sourceforge.net/projects/webwork
>>
>
> I already looked at WebWork, and considered it worth
> investigating. But my current "money generating"
> work requires templating, struts is OK as framework
> ( except of JSP's ).
Struts may be ok, but WebWork is great :-) Besides, this whole thread
started as a way to get the Struts framework to work nicely with
Velocity, and I simply stated that all of the things you want to do
(AFAICT) can already be done much much simpler with WebWork+Velocity.
> And most important is that I can
> sell sacking JSP to my project manager ( due lack of
> performance of my co-developers ), but not struts :)
Having shown WebWork to my project managers: no I wouldn't be able to
sell Struts to them either ;-)
/Rickard
--
Rickard Öberg
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: My $0.02 to Velocity usage (was: Velocity & Struts - redux )
Posted by Konstantin Priblouda <kp...@yahoo.com>.
> Yes, loads. So, instead of putting them all in
> there, why not make it
> possible to define in the template what you need,
> and just put *that*
> there. WebWork allows this by adding a #bean macro
> (to instantiate a
> JavaBean) and a #action macro (to allow things that
> can execute to be
> accessed).
Even read YMTD? Ugly, scary and sort of thing
velocity is trying to avoid :)
> WebWork has a way to map actions to views. Example
> properties config file:
> # Define action alias (used in URL)
> myaction.action=myapp.MyAction
> # Define input view (form)
> myaction.input=myactioninput.xslt
> #Define success and error views
> myaction.success=myaction.vm
> myaction.error=myactionerror.jsp
>
> With failovers and shortcuts possible both on action
> aliases and view
> page/template. (i.e. you can define a global error
> page)
What I like to achive is, good separation between
java code ( to populate context ) and template
( say, between me, hacker, and those sleek types
who are called wob designers and know nothing :) )
I also like it to be completely framework unaware:
We speking just templating here. We do not know ( or
bother ) about actions.
We have just a wiew ( velocity template ) and
class[es] ( mapped as impicitly as possible ) which
populates context for it
To make velocity an JSP killer we need to made it
usage as hassle-free as possible, and mapping actions
to templates ( even if there is no action at all,
like displaying list of some EJB's ) requires some
doctoring on conguguration files.
Template/Implicitely mapped class has advatage of
clear separation between persentation code and data
pulling logic ( and designers can not tweak in
scriptlets... )
What I like to achieve is framework-blind templating
with all the nice features from different templating
systems ( velocity for templating, HTML:Mason
for implicitly mapped code etc. )
> http://sourceforge.net/projects/webwork
I already looked at WebWork, and considered it worth
investigating. But my current "money generating"
work requires templating, struts is OK as framework
( except of JSP's ). And most important is that I can
sell sacking JSP to my project manager ( due lack of
performance of my co-developers ), but not struts :)
regards,
=====
Konstantin Priblouda ( ko5tik ) Freelance Software developer
< http://www.pribluda.de > < play java games -> http://www.yook.de >
< render charts online -> http://www.pribluda.de/povray/ >
__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: My $0.02 to Velocity usage (was: Velocity & Struts - redux )
Posted by Rickard Öberg <ri...@xpedio.com>.
Konstantin Priblouda wrote:
> 1. Use extension mapping ( done )
Done in WebWork too.
> 2. Place template files the same way as every other
> html or jsp or image into war
> [advantages -> designer who knopw how to work with
> jsp,
> would not have any problems with developing ]
> ( done. It required to write simple resource
> loader which does merely "getResourceAsStream()" off
> Servlet context )
Done in WebWork too.
> 3. Made interesting abjects available in context
> ( request , response & session are already there )
Done in WebWork too, although only application objects get placed there
(which most of the time wrap request, response and session objects).
E.g. request parameter "foo"="bar"
-> action.setFoo("bar")
-> action is put in context
-> $foo is valid in code (which will invoke action.getFoo())
This way it is clear from looking at code what parameters you have
available, instead of having to look at what input fields the page
calling you included.
> I can also think of following objects:
> - for URL rewriting
> - skin management ( like in turbine, can be adapted
> almost verbatim )
> - a lot of other stuff
Yes, loads. So, instead of putting them all in there, why not make it
possible to define in the template what you need, and just put *that*
there. WebWork allows this by adding a #bean macro (to instantiate a
JavaBean) and a #action macro (to allow things that can execute to be
accessed).
> Such templating solution can be easily integrated with
> struts (or whatever else which likes to use JSP)
Yes yes yes... been there, done that :-)
> 4. Per-template initialisation code.
> It can be class whose name is located based on
> directory path fo template in question.
> ( say, for /foo/bar/blurge.vm class name would be:
> <configured package prefix>.foo.bar.Blurge )
> Default fallback classes would be also usefull.
> They must be searched and executed in following order:
> ( if configured and existing )
> DefaultContextPopulator,
> <configured prefix>.ContextPopulator,
> <configured prefix>.foo.ContextPopulator,
> <configured prefix>.foo.bar.ContextPopulator
> <configured prefix>.foo.bar.Blurge
>
> (this is something like "autohandler"/"dhandler"
> feature of HTML:Mason, which is very usefull)
WebWork has a way to map actions to views. Example properties config file:
# Define action alias (used in URL)
myaction.action=myapp.MyAction
# Define input view (form)
myaction.input=myactioninput.xslt
#Define success and error views
myaction.success=myaction.vm
myaction.error=myactionerror.jsp
With failovers and shortcuts possible both on action aliases and view
page/template. (i.e. you can define a global error page)
> 5. Different tools can be configured like "tag
> libraries"
> ( and their code/configuration stuff can be generated
> with XDoclet )
WebWork is already integrated with XDoclet, so you can write your code
with XDoclet tags and have the configuration files, containing action
aliases and view mappings, generated as part of your build process.
> I already started to hack on this, so anybody like to
> join?
http://sourceforge.net/projects/webwork
Sorry for being annoying, but IMHO you would be wasting a serious amount
of time, unless there is something fundamentally wrong with WebWork and
you want to do it over (which was the case when Jon told me "been there
done that" when I wrote WebWork instead of using Turbine).
/Rickard
--
Rickard Öberg
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: My $0.02 to Velocity usage (was: Velocity & Struts - redux )
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 11/26/01 9:48 AM, "Konstantin Priblouda" <kp...@yahoo.com> wrote:
> Hi all,
> I was unable to participate in Velocity/Struts
> diskussion for 72 hours due to unability of Deutsche
> Telekom ( they can not fix DSL lines )
>
> Here my EUR 0.02 to this topic.
Which isn't == USD0.02 :)
>
> Velocity has advantages over JSP. But to made it
> usage,
> it has to be as hassle-free as JSP is. So, here is my
> proposal how to do it. I already started to hack on
> such servlet.
I think that it's a fair to start thinking this way, but JSP and Velocity
aren't quite comparable, as you can use velocity an all sorts of places that
you can't use JSP - i.e. JSP is something that is tied very heavily to
servlets.
Now, given that is being overly pendantic, I do agree with you - however,
what you list below is what every framework attempts to provide in some way
or another...
>
> 1. Use extension mapping ( done )
> 2. Place template files the same way as every other
> html or jsp or image into war
> [advantages -> designer who knopw how to work with
> jsp,
> would not have any problems with developing ]
> ( done. It required to write simple resource
> loader which does merely "getResourceAsStream()" off
> Servlet context )
>
> 3. Made interesting abjects available in context
> ( request , response & session are already there )
>
> I can also think of following objects:
> - for URL rewriting
> - skin management ( like in turbine, can be adapted
> almost verbatim )
> - a lot of other stuff
>
> Such templating solution can be easily integrated with
> struts (or whatever else which likes to use JSP)
>
> 4. Per-template initialisation code.
> It can be class whose name is located based on
> directory path fo template in question.
> ( say, for /foo/bar/blurge.vm class name would be:
> <configured package prefix>.foo.bar.Blurge )
> Default fallback classes would be also usefull.
> They must be searched and executed in following order:
> ( if configured and existing )
> DefaultContextPopulator,
> <configured prefix>.ContextPopulator,
> <configured prefix>.foo.ContextPopulator,
> <configured prefix>.foo.bar.ContextPopulator
> <configured prefix>.foo.bar.Blurge
>
> (this is something like "autohandler"/"dhandler"
> feature of HTML:Mason, which is very usefull)
>
> 5. Different tools can be configured like "tag
> libraries"
> ( and their code/configuration stuff can be generated
> with XDoclet )
>
> I already started to hack on this, so anybody like to
> join?
>
I know Rickard talked with you about WebWork, but also look at the
'PumpServlet' (see the powered-by page) as well as the other frameworks on
that page...
--
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>
My $0.02 to Velocity usage (was: Velocity & Struts - redux )
Posted by Konstantin Priblouda <kp...@yahoo.com>.
Hi all,
I was unable to participate in Velocity/Struts
diskussion for 72 hours due to unability of Deutsche
Telekom ( they can not fix DSL lines )
Here my EUR 0.02 to this topic.
Velocity has advantages over JSP. But to made it
usage,
it has to be as hassle-free as JSP is. So, here is my
proposal how to do it. I already started to hack on
such servlet.
1. Use extension mapping ( done )
2. Place template files the same way as every other
html or jsp or image into war
[advantages -> designer who knopw how to work with
jsp,
would not have any problems with developing ]
( done. It required to write simple resource
loader which does merely "getResourceAsStream()" off
Servlet context )
3. Made interesting abjects available in context
( request , response & session are already there )
I can also think of following objects:
- for URL rewriting
- skin management ( like in turbine, can be adapted
almost verbatim )
- a lot of other stuff
Such templating solution can be easily integrated with
struts (or whatever else which likes to use JSP)
4. Per-template initialisation code.
It can be class whose name is located based on
directory path fo template in question.
( say, for /foo/bar/blurge.vm class name would be:
<configured package prefix>.foo.bar.Blurge )
Default fallback classes would be also usefull.
They must be searched and executed in following order:
( if configured and existing )
DefaultContextPopulator,
<configured prefix>.ContextPopulator,
<configured prefix>.foo.ContextPopulator,
<configured prefix>.foo.bar.ContextPopulator
<configured prefix>.foo.bar.Blurge
(this is something like "autohandler"/"dhandler"
feature of HTML:Mason, which is very usefull)
5. Different tools can be configured like "tag
libraries"
( and their code/configuration stuff can be generated
with XDoclet )
I already started to hack on this, so anybody like to
join?
regards,
=====
Konstantin Priblouda ( ko5tik ) Freelance Software developer
< http://www.pribluda.de > < play java games -> http://www.yook.de >
< render charts online -> http://www.pribluda.de/povray/ >
__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity & Struts - redux
Posted by Rickard Öberg <ri...@xpedio.com>.
Rickard Öberg wrote:
> In the template, of course.
>
> Example:
> #action ("MonthList" $monthList)
> $monthList.setMonth($currentMonth)
> #execute($month)
-> #execute($monthList)
--
Rickard Öberg
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity & Struts - redux
Posted by Rickard Öberg <ri...@xpedio.com>.
Geir Magnusson Jr. wrote:
>>Hm...... not following... the above was from a snippet of a *template*
>>using a *bean*.. not the other way round. Or what am I missing? In what
>>way are you suggesting that the code contains markup stuff?
>>
>
> Ok - just to be sure we are talking about the same thing - I am guessing
> that it was some kind of generator for a <select/> or something?
A table, yes.
> So where is the bit that does the generation of the
>
> <select name="month">
> <option value="1">January</option>
> <option value="2">February</option>
> ...
> </select>
>
> Is that in code or in a template somewhere?
In the template, of course.
Example:
#action ("MonthList" $monthList)
$monthList.setMonth($currentMonth)
#execute($month)
<select name="month">
#foreach ($month in $monthList)
<option value="$month.nr">$month.name</option>
#end
</select>
(assuming I got the Velocity syntax right...)
> Just to be sure we are talking about the same thing, I assumed that for the
> case of
>
> #action ("MonthList" $month)
> $month.setMonth($monthnr)
> #execute($month)
>
> That 'MonthList' was some kind of entity that you were going to invoke,
> which you identified above as a bean (class), and that you set things up
> with #action() and then do any config, and the fire with #execute()
Correct.
> So what I am thinking about is how ensure that the designer (or a designer)
> has full control of the output content.
The code designer? Well, he can control the output of his bean, but how
that is used in a template is pretty much up to the webbie.
UNLESS you use WebWork in a Model-2 fashion:
#includeservlet ("MonthList.action?month=12")
where MonthList has been mapped to a particular JavaBean and to a
particular VM template as "view". If the template used to render the
result of the MonthList is written by the Code Designer, then he has
full control over it while avoiding putting template stuff into Java code.
This can be good in a number of cases, such as rendering form controls,
which is often more programmer oriented than graphics designer oriented.
Are we on the same page, or am I missing something?
/R
--
Rickard Öberg
--
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 11/26/01 8:49 AM, "Rickard Öberg" <ri...@xpedio.com> wrote:
> Geir Magnusson Jr. wrote:
>
>>> Nope, it's a JavaBean, or rather, it's a WebWork Action (i.e. a bean
>>> with execute()).
>>
>> But then you run into the problem we have been trying to solve all along,
>> how to keep markup stuff out of code, don't you?
>
>
> Hm...... not following... the above was from a snippet of a *template*
> using a *bean*.. not the other way round. Or what am I missing? In what
> way are you suggesting that the code contains markup stuff?
Ok - just to be sure we are talking about the same thing - I am guessing
that it was some kind of generator for a <select/> or something?
So where is the bit that does the generation of the
<select name="month">
<option value="1">January</option>
<option value="2">February</option>
...
</select>
Is that in code or in a template somewhere?
Just to be sure we are talking about the same thing, I assumed that for the
case of
#action ("MonthList" $month)
$month.setMonth($monthnr)
#execute($month)
That 'MonthList' was some kind of entity that you were going to invoke,
which you identified above as a bean (class), and that you set things up
with #action() and then do any config, and the fire with #execute()
So what I am thinking about is how ensure that the designer (or a designer)
has full control of the output content.
>
>>> Cool, can't wait! Do you have the new Orange Color 2.0 in it? I've been
>>> dying to see that one in action!! :-)
>>>
>>
>> No, but we have the new nasal-compatible fire... What's the riff on this
>> from Hitchhikers Guide? I don't remember...
>>
>
> Easy on the breath, tough on the lungs IIRC. Haven't checked the Guide
> for awhile tho..
>
> /R
--
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 Rickard Öberg <ri...@xpedio.com>.
Geir Magnusson Jr. wrote:
>>Nope, it's a JavaBean, or rather, it's a WebWork Action (i.e. a bean
>>with execute()).
>
> But then you run into the problem we have been trying to solve all along,
> how to keep markup stuff out of code, don't you?
Hm...... not following... the above was from a snippet of a *template*
using a *bean*.. not the other way round. Or what am I missing? In what
way are you suggesting that the code contains markup stuff?
>>Cool, can't wait! Do you have the new Orange Color 2.0 in it? I've been
>>dying to see that one in action!! :-)
>>
>
> No, but we have the new nasal-compatible fire... What's the riff on this
> from Hitchhikers Guide? I don't remember...
>
Easy on the breath, tough on the lungs IIRC. Haven't checked the Guide
for awhile tho..
/R
--
Rickard Öberg
--
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 11/26/01 8:36 AM, "Rickard Öberg" <ri...@xpedio.com> wrote:
> Geir Magnusson Jr. wrote:
>
>>> WebWork supports the above by default, since actions can have optional
>>> arguments. From one of the WebWork examples:
>>> #action ("MonthList" $month)
>>> $month.setMonth($monthnr)
>>> #execute($month)
>>> where #action and #execute are WebWork-specific global macros. The
>>> meaning should be obvious.
>>
>> I assume that MonthList is also a VM?
>
>
> Nope, it's a JavaBean, or rather, it's a WebWork Action (i.e. a bean
> with execute()).
But then you run into the problem we have been trying to solve all along,
how to keep markup stuff out of code, don't you?
>
>> And how do you make it clear what is
>> optional, and what isn't?
>
>
> From the JavaDoc of the bean.
And now you can Velocidoc VMs :)
>>> I guess you *could* reinvent the wheel by copying how WebWork already
>>> works, but what would be the point really... 8-)
>>>
>>
>> That's what we do here :) We also have a new version of 'fire' coming out
>> as well...
>
> Cool, can't wait! Do you have the new Orange Color 2.0 in it? I've been
> dying to see that one in action!! :-)
No, but we have the new nasal-compatible fire... What's the riff on this
from Hitchhikers Guide? I don't remember...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity & Struts - redux
Posted by Rickard Öberg <ri...@xpedio.com>.
Geir Magnusson Jr. wrote:
>>WebWork supports the above by default, since actions can have optional
>>arguments. From one of the WebWork examples:
>> #action ("MonthList" $month)
>> $month.setMonth($monthnr)
>> #execute($month)
>>where #action and #execute are WebWork-specific global macros. The
>>meaning should be obvious.
>
> I assume that MonthList is also a VM?
Nope, it's a JavaBean, or rather, it's a WebWork Action (i.e. a bean
with execute()).
> And how do you make it clear what is
> optional, and what isn't?
From the JavaDoc of the bean.
>>I guess you *could* reinvent the wheel by copying how WebWork already
>>works, but what would be the point really... 8-)
>>
>
> That's what we do here :) We also have a new version of 'fire' coming out
> as well...
Cool, can't wait! Do you have the new Orange Color 2.0 in it? I've been
dying to see that one in action!! :-)
/R
--
Rickard Öberg
--
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 11/26/01 8:20 AM, "Rickard Öberg" <ri...@xpedio.com> wrote:
> Geir Magnusson Jr. wrote:
>
>> Maybe we can get some good ideas from WebWork on how they did this, as they
>> seemed to have done something like this already...
>
>
> Simple: put all logic in JavaBeans and make tags nothing more than
> syntactic sugar. Then you can use them from JSP, Velocity or Swing apps.
> Or whatever.
>
>
>>> One thing to ponder: Tag libs support optional arguments. How would we
>>> map this to Velocity? Can the concept of VelociMacros be extended to support
>>> this?
>>>
>>
>> Hm. I can imagine a few ways to do this, all of which are yecchy. How do
>> taglibs support optional args? By way of properties?
>
>
> <x:foo aprop="x" bprop="y"/>
> <x:foo aprop="x"/>
>
> I.e. bprop was an optional arg.
So it's properties...
>
>> I guess we need to figure out if we can live with something like
>>
>> #set($foo.arg1 = "bar")
>> #set($foo.arg2 = "baz")
>> #table( $foo )
>
> This would be the closest I think, but you need to figure out a way to
> make it possible to describe these properties so that one knows what is
> optional and what is not.
Yep
>
>> In pure Velocimacros, or using a tool :
>>
>> $foo.setArg1("bar")
>> $foo.setArg2("baz")
>>
>> (or use the #set() approach above - same thing) and then
>>
>> $foo.invoke()
>>
>> Where the $foo object invokes a VM from a library - the idea here is that we
>> still keep the view stuff in template, as is our creed :D but use a tool to
>> help with the args and invocation.
>
>
> You're describing WebWork :-) The "tool" would be WW.
>
> WebWork supports the above by default, since actions can have optional
> arguments. From one of the WebWork examples:
> #action ("MonthList" $month)
> $month.setMonth($monthnr)
> #execute($month)
> where #action and #execute are WebWork-specific global macros. The
> meaning should be obvious.
>
I assume that MonthList is also a VM? And how do you make it clear what is
optional, and what isn't?
> I guess you *could* reinvent the wheel by copying how WebWork already
> works, but what would be the point really... 8-)
That's what we do here :) We also have a new version of 'fire' coming out
as well...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - 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 Rickard Öberg <ri...@xpedio.com>.
Geir Magnusson Jr. wrote:
> Maybe we can get some good ideas from WebWork on how they did this, as they
> seemed to have done something like this already...
Simple: put all logic in JavaBeans and make tags nothing more than
syntactic sugar. Then you can use them from JSP, Velocity or Swing apps.
Or whatever.
>>One thing to ponder: Tag libs support optional arguments. How would we
>>map this to Velocity? Can the concept of VelociMacros be extended to support
>>this?
>>
>
> Hm. I can imagine a few ways to do this, all of which are yecchy. How do
> taglibs support optional args? By way of properties?
<x:foo aprop="x" bprop="y"/>
<x:foo aprop="x"/>
I.e. bprop was an optional arg.
> I guess we need to figure out if we can live with something like
>
> #set($foo.arg1 = "bar")
> #set($foo.arg2 = "baz")
> #table( $foo )
This would be the closest I think, but you need to figure out a way to
make it possible to describe these properties so that one knows what is
optional and what is not.
> In pure Velocimacros, or using a tool :
>
> $foo.setArg1("bar")
> $foo.setArg2("baz")
>
> (or use the #set() approach above - same thing) and then
>
> $foo.invoke()
>
> Where the $foo object invokes a VM from a library - the idea here is that we
> still keep the view stuff in template, as is our creed :D but use a tool to
> help with the args and invocation.
You're describing WebWork :-) The "tool" would be WW.
WebWork supports the above by default, since actions can have optional
arguments. From one of the WebWork examples:
#action ("MonthList" $month)
$month.setMonth($monthnr)
#execute($month)
where #action and #execute are WebWork-specific global macros. The
meaning should be obvious.
I guess you *could* reinvent the wheel by copying how WebWork already
works, but what would be the point really... 8-)
/Rickard
--
Rickard Öberg
--
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>.
Geir,
This is why I asked the question about name-value macros earlier. I'm
mid-thread, so I'll see what else is discussed...
Donnie
-----Original Message-----
From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
Sent: Monday, November 26, 2001 7:24 AM
To: velocity-user@jakarta.apache.org
Subject: Re: Velocity & Struts - redux
On 11/26/01 12:35 AM, "Gabriel Sidler" <si...@teamup.ch> wrote:
> "Geir Magnusson Jr." wrote:
> [..]
>> So we can rip those off. I haven't seen the code - but it's been a
dream
>> of mine to take some of these useful taglibs, refactor them so that you
can
>> get at the functionality w/o having to mock up the environment (although
>> that is another idea...), and then reuse them as tools in Velocity.
>
> Geir,
> That is exactly what I think, too. It would be great to be able to reuse
> existing JSP tag libs.
Maybe we can get some good ideas from WebWork on how they did this, as they
seemed to have done something like this already...
> One thing to ponder: Tag libs support optional arguments. How would we
> map this to Velocity? Can the concept of VelociMacros be extended to
support
> this?
Hm. I can imagine a few ways to do this, all of which are yecchy. How do
taglibs support optional args? By way of properties?
I guess we need to figure out if we can live with something like
#set($foo.arg1 = "bar")
#set($foo.arg2 = "baz")
#table( $foo )
In pure Velocimacros, or using a tool :
$foo.setArg1("bar")
$foo.setArg2("baz")
(or use the #set() approach above - same thing) and then
$foo.invoke()
Where the $foo object invokes a VM from a library - the idea here is that we
still keep the view stuff in template, as is our creed :D but use a tool to
help with the args and invocation.
--
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>
--
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 11/26/01 12:35 AM, "Gabriel Sidler" <si...@teamup.ch> wrote:
> "Geir Magnusson Jr." wrote:
> [..]
>> So we can rip those off. I haven't seen the code - but it's been a dream
>> of mine to take some of these useful taglibs, refactor them so that you can
>> get at the functionality w/o having to mock up the environment (although
>> that is another idea...), and then reuse them as tools in Velocity.
>
> Geir,
> That is exactly what I think, too. It would be great to be able to reuse
> existing JSP tag libs.
Maybe we can get some good ideas from WebWork on how they did this, as they
seemed to have done something like this already...
> One thing to ponder: Tag libs support optional arguments. How would we
> map this to Velocity? Can the concept of VelociMacros be extended to support
> this?
Hm. I can imagine a few ways to do this, all of which are yecchy. How do
taglibs support optional args? By way of properties?
I guess we need to figure out if we can live with something like
#set($foo.arg1 = "bar")
#set($foo.arg2 = "baz")
#table( $foo )
In pure Velocimacros, or using a tool :
$foo.setArg1("bar")
$foo.setArg2("baz")
(or use the #set() approach above - same thing) and then
$foo.invoke()
Where the $foo object invokes a VM from a library - the idea here is that we
still keep the view stuff in template, as is our creed :D but use a tool to
help with the args and invocation.
--
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 Gabriel Sidler <si...@teamup.ch>.
"Geir Magnusson Jr." wrote:
[..]
> So we can rip those off. I haven't seen the code - but it's been a dream
> of mine to take some of these useful taglibs, refactor them so that you can
> get at the functionality w/o having to mock up the environment (although
> that is another idea...), and then reuse them as tools in Velocity.
Geir,
That is exactly what I think, too. It would be great to be able to reuse
existing JSP tag libs.
One thing to ponder: Tag libs support optional arguments. How would we
map this to Velocity? Can the concept of VelociMacros be extended to support
this?
Gabe
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
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>.
[Fell off of this thread - away for a few days... I will catch up to
previous... ]
On 11/25/01 2:08 AM, "Tim Colson" <tc...@cisco.com> wrote:
> Donnie -
>
>>>> OK. I would favor an approach that does not touch the Struts source. Not
>> even extending it. I believe this is possible. This will make it much
>> easier to keep up with future development of Struts.<<
>
> As I learn more about Struts, I'm starting to think modification of the
> Struts source may be a good long term idea for easier maintenance. Let me
> explain:
>
> The Struts Camp is driving with only JSP's in mind; consequently, updates
> and add-ons are JSP centric (ex. Dave Winterfeldt's excellent form Validator
> package extends ActionForm, and provides taglibs which create dynamic client
> side javascript.)
So we can rip those off. I haven't seen the code - but it's been a dream
of mine to take some of these useful taglibs, refactor them so that you can
get at the functionality w/o having to mock up the environment (although
that is another idea...), and then reuse them as tools in Velocity.
If we could do that, then I think we can stay on the straight and narrow
path of not modifying struts. I am not sure how welcoming the Struts
community would be to modifications just to support us.
> I believe this JSP bias will make a Struts-Velocity bridge hard to maintain
> (ex. How will I use a Velocity only view and still gain the advantages of
> the Validator package without additional work to the Glue/Bridge? BTW, this
> pkg will be part of Struts 1.1 real soon now.)
What does that do? I'll go look...
>
> Up until now, Geir has been the only voice on the Struts list to suggest
> Velocity as a JSP alternative. Perhaps more of us should subscribe to the
> struts-user list and say, "Hey guys, great work on this Struts stuff... but
> can we help out to decouple the view and build support out of the box for
> more options like Velocity?" :-)
I think we would be in a stronger position if we came to them saying that,
but with a working example, and always being careful to not displace JSP,
but show how they work together. It's a lot less threatening that way - and
that's all we are saying - give people the choice... If people don't go for
velocity when all things are equal, then either we're delusional about the
templating thing, or there is something to JSP that we are missing...
> (In the shorter term, it still might be more persuasive if we can show
> Velocity and Struts playing together nicely. Expanding on Geirs remarkable
> re-work of the Struts example app, and/or Ted Husted's struts-simple.war on
> husted.com, to show ease of use of Velocity versus JSP might be helpful
> too.)
I should have read ahead :) you said the same thing.
+1
And Ted's a nice guy - it would be fun to see if he will host a
struts-simple-velocity.war or something...
geir
>
> ---
>>>> To [Gabe] sessions are an important concept of a Web application....
>>>> [Gabe] don't find this very managable. And it is different
>>>> from anything known to developers (JSP, Servlet API).
>>> [Donnie] do agree that a structured context is better.
>
> There's been discussion before on this. I think Geir had it mostly right
> saying that scopes are important but are the province of the Servlet
> DEVELOPER. They are of little use and likely confusion for the Template
> DESIGNER.
>
> I believe that a Template Designer should expect $thingy to simply get a
> value - from wherever it lives. This can be accomplished by the Developer
> flattening the scopes into one context which is simple, effective, and what
> Geir did. ;-)
>
> One potential drawback to an AUTOMATED* flattening approach is possible
> namespace overlap/collisions. A Developer could write an Application scoped
> object $thingy, and s/he wouldn't expect it to clash with a request scoped
> $thingy.
> (*Presumably if the Developer were creating the context manually, they would
> be smart enough to populate $thingy with Req.thing, or Session.thing.)
>
> So assuming $thingy lives in potentialy all scopes, perhaps the following
> could happen:
>
> Populate context in the order request->session->app, the first time an
> object is seen, it gets stuck into $thingy. But also prepend a scope
> qualifier ex. $request.preference, $session.preference or $app.preference
> for access directly if needed.
>
> FYI - this complexity of naming scopes seeping into the View makes me think
> that if Struts code was less JSP centric, population of a context wouldn't
> be so mangled.
>
> Donnie wrote:
>> Now, when VelServlet runs, it retrieves that item from
>> the request. If the object implements a "ContextPopulator" interface,
>> VelServlet invokes it. Presumably, the object would have all the info it
>> needs to fill the VelocityContext without accessing the various servlet
>> contexts. If it doesn't implement that interface, VelServlet can
>> stuff it in the VelocityContext using that name so that
>> it's more directly available
>> than it would be going through the request.
>
> (I'm going to ramble here a bit... please don't bite. )
>
> Hmmm...howabout this simpler variation on that theme:
>
> Developers populate a 'context' hash in the Struts Action, then they stick
> that hash into the request, and this the only object that the VelServlet
> uses for the Velocity Context. VelServlet would copy all keys from this
> known-good object "VelocityContext" into a real Velocity context object.
>
> Developers would handle scopes and objects normally - only placing those
> items they feel are needed into the context. They could stick the current
> ActionForm object in there. Context Tools. Even the wrapped Messages object.
> Errors objects could be stuck in there from the form.validate() methods.
>
> This enables a Developer to put whatever is _needed_ into the context. If
> they feel that the entire request object is truly necessary, they can shove
> it in there. And it allows Designers easy access to whatever is in there
> without having to chant $request.get("user").FirstName - just
> $user.FirstName would do.
>
> If there is an Application scoped 'preference' as well as a request and
> session pref... they can put in whichever is pertinent, using whatever
> naming convention suites them.
>
> Questions:
> 1) Is it really that easy - what am I missing?
> 2) How performance ugly is it to populate a hash, and then use it to
> populate the Velocity context?
> 3) Is there any reason not to simply populate a real Velocity Context
> directly in the Struts Action and pass that to the VelServlet?
>
> --
>
>> Is it important that the solution allow for
>> direct requests of .vm files? If so, how should that work?
> I think so - need that for example during form based login (login.jsp).
> However, I'd expect that for this type of request, it'd be no different
> really. The context would simply be a lot emptier. ;-)
>
> Other bits:
>
> Templates/Layouts - to me this is the biggest ugliness of Struts that needs
> to be addressed. Right now, we're using the TEMPLATE taglib in one JSP which
> sets some items including the main body in a second JSP and then calls up
> one of the global page layout JSPs, which inserts the items. There has been
> a lot of recent discussion on this topic lately...but it was unclear to me
> if something definitive came out of it.
> FYI - Using the Struts template: taglib, the first JSP would include the
> correct body JSP and assign it to the generic label 'BODY'... and then the
> template tag pulls in the 'layout.jsp' which inserts 'BODY' wherever it
> goes.
> I'd like to see the VelServlet handle this in some way without the need for
> that first page... perhaps by passing in 'Velocity.LAYOUT' and one or more
> 'Velocity.TEMPLATE' params in the context, VelServlet could dynamically
> merge template bits into the layout.
>
> HTML Taglibs replaced with Macros would be a good idea. (right now, I don't
> like the custom html:foo taglibs because they hide the 'real HTML' inside
> java taglib code...icky, a global macro would be easier to see what's
> happening under the covers by the Designer)
>
>
> Cheers,
> Timo
>
>
> --
> 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 Tim Colson <tc...@cisco.com>.
Donnie -
> >>OK. I would favor an approach that does not touch the Struts source. Not
> even extending it. I believe this is possible. This will make it much
> easier to keep up with future development of Struts.<<
As I learn more about Struts, I'm starting to think modification of the
Struts source may be a good long term idea for easier maintenance. Let me
explain:
The Struts Camp is driving with only JSP's in mind; consequently, updates
and add-ons are JSP centric (ex. Dave Winterfeldt's excellent form Validator
package extends ActionForm, and provides taglibs which create dynamic client
side javascript.)
I believe this JSP bias will make a Struts-Velocity bridge hard to maintain
(ex. How will I use a Velocity only view and still gain the advantages of
the Validator package without additional work to the Glue/Bridge? BTW, this
pkg will be part of Struts 1.1 real soon now.)
Up until now, Geir has been the only voice on the Struts list to suggest
Velocity as a JSP alternative. Perhaps more of us should subscribe to the
struts-user list and say, "Hey guys, great work on this Struts stuff... but
can we help out to decouple the view and build support out of the box for
more options like Velocity?" :-)
(In the shorter term, it still might be more persuasive if we can show
Velocity and Struts playing together nicely. Expanding on Geirs remarkable
re-work of the Struts example app, and/or Ted Husted's struts-simple.war on
husted.com, to show ease of use of Velocity versus JSP might be helpful
too.)
---
>>> To [Gabe] sessions are an important concept of a Web application....
>>> [Gabe] don't find this very managable. And it is different
>>> from anything known to developers (JSP, Servlet API).
>> [Donnie] do agree that a structured context is better.
There's been discussion before on this. I think Geir had it mostly right
saying that scopes are important but are the province of the Servlet
DEVELOPER. They are of little use and likely confusion for the Template
DESIGNER.
I believe that a Template Designer should expect $thingy to simply get a
value - from wherever it lives. This can be accomplished by the Developer
flattening the scopes into one context which is simple, effective, and what
Geir did. ;-)
One potential drawback to an AUTOMATED* flattening approach is possible
namespace overlap/collisions. A Developer could write an Application scoped
object $thingy, and s/he wouldn't expect it to clash with a request scoped
$thingy.
(*Presumably if the Developer were creating the context manually, they would
be smart enough to populate $thingy with Req.thing, or Session.thing.)
So assuming $thingy lives in potentialy all scopes, perhaps the following
could happen:
Populate context in the order request->session->app, the first time an
object is seen, it gets stuck into $thingy. But also prepend a scope
qualifier ex. $request.preference, $session.preference or $app.preference
for access directly if needed.
FYI - this complexity of naming scopes seeping into the View makes me think
that if Struts code was less JSP centric, population of a context wouldn't
be so mangled.
Donnie wrote:
> Now, when VelServlet runs, it retrieves that item from
> the request. If the object implements a "ContextPopulator" interface,
> VelServlet invokes it. Presumably, the object would have all the info it
> needs to fill the VelocityContext without accessing the various servlet
> contexts. If it doesn't implement that interface, VelServlet can
> stuff it in the VelocityContext using that name so that
> it's more directly available
> than it would be going through the request.
(I'm going to ramble here a bit... please don't bite. )
Hmmm...howabout this simpler variation on that theme:
Developers populate a 'context' hash in the Struts Action, then they stick
that hash into the request, and this the only object that the VelServlet
uses for the Velocity Context. VelServlet would copy all keys from this
known-good object "VelocityContext" into a real Velocity context object.
Developers would handle scopes and objects normally - only placing those
items they feel are needed into the context. They could stick the current
ActionForm object in there. Context Tools. Even the wrapped Messages object.
Errors objects could be stuck in there from the form.validate() methods.
This enables a Developer to put whatever is _needed_ into the context. If
they feel that the entire request object is truly necessary, they can shove
it in there. And it allows Designers easy access to whatever is in there
without having to chant $request.get("user").FirstName - just
$user.FirstName would do.
If there is an Application scoped 'preference' as well as a request and
session pref... they can put in whichever is pertinent, using whatever
naming convention suites them.
Questions:
1) Is it really that easy - what am I missing?
2) How performance ugly is it to populate a hash, and then use it to
populate the Velocity context?
3) Is there any reason not to simply populate a real Velocity Context
directly in the Struts Action and pass that to the VelServlet?
--
> Is it important that the solution allow for
> direct requests of .vm files? If so, how should that work?
I think so - need that for example during form based login (login.jsp).
However, I'd expect that for this type of request, it'd be no different
really. The context would simply be a lot emptier. ;-)
Other bits:
Templates/Layouts - to me this is the biggest ugliness of Struts that needs
to be addressed. Right now, we're using the TEMPLATE taglib in one JSP which
sets some items including the main body in a second JSP and then calls up
one of the global page layout JSPs, which inserts the items. There has been
a lot of recent discussion on this topic lately...but it was unclear to me
if something definitive came out of it.
FYI - Using the Struts template: taglib, the first JSP would include the
correct body JSP and assign it to the generic label 'BODY'... and then the
template tag pulls in the 'layout.jsp' which inserts 'BODY' wherever it
goes.
I'd like to see the VelServlet handle this in some way without the need for
that first page... perhaps by passing in 'Velocity.LAYOUT' and one or more
'Velocity.TEMPLATE' params in the context, VelServlet could dynamically
merge template bits into the layout.
HTML Taglibs replaced with Macros would be a good idea. (right now, I don't
like the custom html:foo taglibs because they hide the 'real HTML' inside
java taglib code...icky, a global macro would be easier to see what's
happening under the covers by the Designer)
Cheers,
Timo
--
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>.
Gabe,
>>OK. I would favor an approach that does not touch the Struts source. Not
even extending it. I believe this is possible. This will make it much
easier to keep up with future development of Struts.<<
I can understand that reasoning.
>>I am not sure I understand what you mean by "minimize/eliminate session
usage".
To me sessions are an important concept of a Web application. Sessions are
propagated by the Servlet API (not Struts). How would you deal with sessions
instead?<<
Struts uses contexts (request/session/servlet) ***very extensively*** to
store info (too extensively, IMO). One of the reasons why is that there's an
assumption that view rendering will always occur after a forward/redirect
and thus those are the only hooks to get back at the info the view needs to
do its job. If view rendering happened immediately after processing the
action, much of the need for using that stuff would go away. I see the need
for session usage as one progresses through pages that make up a whole
scenario - that's unavoidable. But using the contexts as a server-side state
repository for implicit parameter passing goes against their intention, IMO.
>>That is now how it see it. In Struts, the form bean is only representing
the request parameters. In my unterstanding the context should be everything
that you have available when executing the service() method of class
HttpServlet.
This includes all members of class HttpServlet as well as instances
of HttpRequest and HttpRespose. The Struts form bean can be accessed from
the HttpRequest instance.<<
You're correct. I just saw some old Struts list messages that better
explained the design goals for ActionForms. My question now is, "why isn't
the design for supplying info to the view after processing the ActionForm
more formalized?"
>>I my view the forwarding in Struts is an elegant concept to introduce a
configurable indirection between the C of MVC (Action classes) and the
V of MVC(JSP pages). I would definately stick with this concept. Why would
you want to get rid of forwarding?<<
See above, for one thing. I see forwarding as only required because JSPs
*must* run in their own servlet; so there's no alternative to doing that.
But in an architecture that doesn't presume forwarding, you can still have
the decoupling of C and V.
>>Yes!<<
Gotcha.
>>>
I agree with Geir's approach to using a second servlet (a Velocity servlet)
to which control is forwarded for generating the view. I find this a simple
and flexible approach. And, it is the same that Struts does with JSP pages.
Where I don't quite agree with Geir is how the Velocity context should be
filled. He creates a large flat context with all the relevant items from the
request, the session, the servlet context, etc. I don't find this very
managable. And it is different from anything known to developers (JSP,
Servlet
API).
I would propose to borrow here some ideas from JSP (Auaa...). Stick the
following objects into the Velocity context:
Name Class Scope
request javax.servlet.ServletRequest Request
session javax.servlet.http.HttpSession Session
application javax.servlet.ServletContext Application
pageContext javax.servlet.jsp.PageContext Page
config javax.servlet.ServletConfig Application
<<<
In the normal case, there won't be a jsp.PageContext, will there? That only
gets created as an artifact of the JSP being compiled into a servlet and
then having been invoked, right? So in a JSP-free environment, there won't
be one.
I do agree that a structured context is better. My first issue more lies
with shoving everything that Struts shoves in the contexts in the
VelocityContext. For example, Struts puts datasources in the ServletContext.
A view will never need those (I hope :). My second issue has to do with one
of Velocity's core premises, and that is that a view-specific "API" will be
communicated to the view developer. I don't think it's good to ask the view
developer to have to navigate the servlet API / contexts to get the view
info they need. In the normal case, I'd think it better to be able to fill
the VelocityContext as it would be without Struts. That doesn't necessarily
mean the appropriate things from the servlet contexts couldn't also be
available; just that they wouldn't be the primary source of view info.
To support that, we likely have to make the "VelServlet" fancier to allow
the Java developers to fill the VelocityContext with the expected view
"API". I'll go back to something I hinted at in my previous message. Let's
say we recommend a design approach for Actions that will be part of a
Velocity-based application that they put something in the request that can
be retrieved when "VelServlet" runs. Right now, I'm not sure if this could
be via a single, well-known name or if the name would need to become a
parameter somehow (I'd love to avoid more config files if possible - another
design constraint :). Now, when VelServlet runs, it retrieves that item from
the request. If the object implements a "ContextPopulator" interface,
VelServlet invokes it. Presumably, the object would have all the info it
needs to fill the VelocityContext without accessing the various servlet
contexts. If it doesn't implement that interface, VelServlet can stuff it in
the VelocityContext using that name so that it's more directly available
than it would be going through the request.
>>Your approach required several extensions to Struts. Can you help me to
understand the advantages of this?<<
I see where you're coming from. I think part of my motivation is in making
Struts work more the way I think it should - i.e. overcoming some of its JSP
bias. Maybe that's not really a concern for what we're trying to accomplish
here.
One other question came to mind: Is it important that the solution allow for
direct requests of .vm files? If so, how should that work?
Donnie
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity & Struts - redux
Posted by Gabriel Sidler <si...@teamup.ch>.
Hi Donnie,
I am happy to see other people interested in Struts and Velocity. I have
looked into Struts and Velocity integration a while ago and am still very
much interested to get this working. I promised the list back in September
to work on this in November, after my current project. Now my project is
one month late and therefore I haven't had much time to do anything
so far. I should be done by the end of this month. I am currently working
on a Struts/JSP project and this helps me to get some insight into the issues
to be adressed. I added some comments below.
Donnie Hale wrote:
[...]
> First, we should agree on an operating set of goals/constraints/assumptions.
> As a start here's some I've considered:
>
> - keep Struts' actions, mapping, forwarding, form bean capabilities, message
> resources, file upload support, etc.
OK
> - eliminate all .tld's, custom tag/tei sources from projects, config files,
> deployment descriptors, etc.
OK
> - make no changes to Struts source code (though extending it in the spirit
> Struts intends is fine)
OK. I would favor an approach that does not touch the Struts source. Not
even extending it. I believe this is possible. This will make it much
easier to keep up with future development of Struts.
> - minimize/eliminate session usage by view (acceptable for form bean
> management by controller) is this important/feasible???
I am not sure I understand what you mean by "minimize/eliminate session usage".
To me sessions are an important concept of a Web application. Sessions are
propagated by the Servlet API (not Struts). How would you deal with sessions
instead?
> - form bean is logically equivalent to the Velocity context
That is now how it see it. In Struts, the form bean is only representing
the request parameters. In my unterstanding the context should be everything
that you have available when executing the service() method of class HttpServlet.
This includes all members of class HttpServlet as well as instances
of HttpRequest and HttpRespose.
The Struts form bean can be accessed from the HttpRequest instance.
> - forwarding is used so extensively now because the views are JSPs and thus
> must be handled by a separate servlet; would it be better/cleaner/more
> elegant/more efficient to minimize/eliminate forwarding?
I my view the forwarding in Struts is an elegant concept to introduce a
configurable indirection between the C of MVC (Action classes) and the
V of MVC(JSP pages). I would definately stick with this concept. Why would
you want to get rid of forwarding?
> - would a library of macros modelled after Struts' html:form tag library be
> useful/important?
Yes!
> Second, if we pursue Geir's approach using a second servlet to which
> Velocity templates get forwarded, how do we flesh out what he's done so far?
> His approach right now is to just fill a standard VelocityContext with all
> the cruff that Struts sticks in the servlet context, session, and request.
> One thought I had was to implement a "StrutsVelocityContext" which
> formalizes access to those elements. Don't know if that makes sense or not.
> One thing I would like to do is only provide access to those things which
> the view could reasonably need. For example, it shouldn't need the stuff
> identified by "DATA_SOURCE". As Geir has paved the way on this approach, it
> may not be too far from being "real".
I agree with Geir's approach to using a second servlet (a Velocity servlet)
to which control is forwarded for generating the view. I find this a simple
and flexible approach. And, it is the same that Struts does with JSP pages.
Where I don't quite agree with Geir is how the Velocity context should be
filled. He creates a large flat context with all the relevant items from the
request, the session, the servlet context, etc. I don't find this very
managable. And it is different from anything known to developers (JSP, Servlet
API).
I would propose to borrow here some ideas from JSP (Auaa...). Stick the
following objects into the Velocity context:
Name Class Scope
request javax.servlet.ServletRequest Request
session javax.servlet.http.HttpSession Session
application javax.servlet.ServletContext Application
pageContext javax.servlet.jsp.PageContext Page
config javax.servlet.ServletConfig Application
I see several advantages of such a structured context vs. a flat context:
+ I believe it's easier to navigate a structured context.
+ For the developer of an application it is important to understand the scope
of each object in the context. The structured context proposed above makes it
more explicit what the scope is compared to a large flat context.
+ I can use the Servlet API documentation to navigate the context. It's good
to stick to something that is known, understood and well documented.
+ Communication with Struts people will be easier than if we use a context
that has a very different layout than theirs.
Through the context above we gain access to all Struts relevant information as
well. For example, the form bean can be retriev from the request with
request.getAttribute("NameOfForm"). For convenience we might add a reference to
the form bean explicitely to the context.
> Third, here's some stream-of-consciousness thought I had regarding an
> alternate approach. I think it might be more work and may fit less well
> given some of the premises Struts makes (it would be nice to have some
> insight into any major design changes that are in upcoming versions of
> Struts). Anyway, my thinking was related to eliminating the
> RequestDispatcher.forward step, which causes the need for some of the stuff
> to be shoved in the request/session.
What is your motivation to get rid of the forwarding step. I find this a
useful indirection between C and V.
> So, here goes:
>
> 1. implement a VelocityActionForward class extended from ActionForward
> - specify it as the "className" attribute for any forward declarations in
> struts-config.xml where the path is a Velocity template file; e.g.
>
> <forward name="next" path="/order/entry.vm"
> className="org.apache.velocity.struts.VelocityActionForward" />
>
> - the <forward> elements can have additional <set-property> child elements;
> that may be important to take advantage of for context construction (see
> below)
>
> An action can use current the Struts mechanism to get the ActionForward
> object by name; i.e. mapping.findForward(name). For forwards declared with
> this new class, the instance will be of this type.
>
> 2. subclass ActionServlet
> - add init() functionality to initialize Velocity as the VelocityServlet /
> VelServlet servlets do
> - add functionality to directly handle requests for Velocity templates so
> that we can still specify a servlet-mapping in web.xml
> - override the processActionForward method
>
> In that method, we'll delegate to super.processActionForward if (!forward
> instanceof VelocityActionForward). If the "forward" is a
> VelocityActionForward, then this method will construct a context, retrieve
> the template, and do the standard merging/rendering.
>
> An issue with this approach is the implicit forwarding in the event of
> validation errors, so that could mean more overridden functionality.
>
> 3. constructing the context
> This is the part I haven't completely solved yet. processActionForward is
> passed the ActionForm (form bean) instance. So the "model" is available.
The form bean is only part of the model, if at all. I my past applications most
of the model is accessed through a session object.
> The
> easy solution is to put the form bean in the context with a name and define
> the API for the template with an extra level of indirection (i.e. rather
> than properties in the context, each with a different name, there's a single
> property in the context with lots of properties/methods on it). Another idea
> is to allow form beans to optionally implement a "ContextPopulator"
> interface, having a "void populate(VelocityContext)" method on it. If the
> form beans do implement that interface, then they have complete control over
> what goes in the context. If not, then default action takes place. This idea
> could work using Geir's approach as well. There may be a more elegant
> solution that hasn't occurred to me yet.
>
Your approach required several extensions to Struts. Can you help me to
understand the advantages of this?
I would favor an approach that sticks as much as possible with Struts as
is. This will make it much easier to keep up with future developments of
Struts and it will be easier to convince Strusts developers to using
Velocity.
> Again, sorry for the length. Please respond with comments,
>
> Donnie
>
I look forward to further discuss this. I am commited to get this Struts/Velocity
integration working.
Gabe
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
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>.
Geir,
Thanks for the response. Re. making a good run at this, I wholeheartedly
agree. I've spent some time looking into this today, and here are my
thoughts/ideas (forgive the length).
First, we should agree on an operating set of goals/constraints/assumptions.
As a start here's some I've considered:
- keep Struts' actions, mapping, forwarding, form bean capabilities, message
resources, file upload support, etc.
- eliminate all .tld's, custom tag/tei sources from projects, config files,
deployment descriptors, etc.
- make no changes to Struts source code (though extending it in the spirit
Struts intends is fine)
- minimize/eliminate session usage by view (acceptable for form bean
management by controller) is this important/feasible???
- form bean is logically equivalent to the Velocity context
- forwarding is used so extensively now because the views are JSPs and thus
must be handled by a separate servlet; would it be better/cleaner/more
elegant/more efficient to minimize/eliminate forwarding?
- would a library of macros modelled after Struts' html:form tag library be
useful/important?
Second, if we pursue Geir's approach using a second servlet to which
Velocity templates get forwarded, how do we flesh out what he's done so far?
His approach right now is to just fill a standard VelocityContext with all
the cruff that Struts sticks in the servlet context, session, and request.
One thought I had was to implement a "StrutsVelocityContext" which
formalizes access to those elements. Don't know if that makes sense or not.
One thing I would like to do is only provide access to those things which
the view could reasonably need. For example, it shouldn't need the stuff
identified by "DATA_SOURCE". As Geir has paved the way on this approach, it
may not be too far from being "real".
Third, here's some stream-of-consciousness thought I had regarding an
alternate approach. I think it might be more work and may fit less well
given some of the premises Struts makes (it would be nice to have some
insight into any major design changes that are in upcoming versions of
Struts). Anyway, my thinking was related to eliminating the
RequestDispatcher.forward step, which causes the need for some of the stuff
to be shoved in the request/session. So, here goes:
1. implement a VelocityActionForward class extended from ActionForward
- specify it as the "className" attribute for any forward declarations in
struts-config.xml where the path is a Velocity template file; e.g.
<forward name="next" path="/order/entry.vm"
className="org.apache.velocity.struts.VelocityActionForward" />
- the <forward> elements can have additional <set-property> child elements;
that may be important to take advantage of for context construction (see
below)
An action can use current the Struts mechanism to get the ActionForward
object by name; i.e. mapping.findForward(name). For forwards declared with
this new class, the instance will be of this type.
2. subclass ActionServlet
- add init() functionality to initialize Velocity as the VelocityServlet /
VelServlet servlets do
- add functionality to directly handle requests for Velocity templates so
that we can still specify a servlet-mapping in web.xml
- override the processActionForward method
In that method, we'll delegate to super.processActionForward if (!forward
instanceof VelocityActionForward). If the "forward" is a
VelocityActionForward, then this method will construct a context, retrieve
the template, and do the standard merging/rendering.
An issue with this approach is the implicit forwarding in the event of
validation errors, so that could mean more overridden functionality.
3. constructing the context
This is the part I haven't completely solved yet. processActionForward is
passed the ActionForm (form bean) instance. So the "model" is available. The
easy solution is to put the form bean in the context with a name and define
the API for the template with an extra level of indirection (i.e. rather
than properties in the context, each with a different name, there's a single
property in the context with lots of properties/methods on it). Another idea
is to allow form beans to optionally implement a "ContextPopulator"
interface, having a "void populate(VelocityContext)" method on it. If the
form beans do implement that interface, then they have complete control over
what goes in the context. If not, then default action takes place. This idea
could work using Geir's approach as well. There may be a more elegant
solution that hasn't occurred to me yet.
Again, sorry for the length. Please respond with comments,
Donnie
--
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 11/20/01 9:42 PM, "Tim Colson" <tc...@cisco.com> wrote:
>> Is there any chance I can get that? Has it ever been put in CVS? (Not much
>> of a CVS expert - thus the question...)
>
> I had that same question myself a few weeks ago, found them "on display in
> the bottom of a locked filing cabinet stuck in a disused lavatory with a
> sign on the door saying 'Beware of the Leopard.' " ... err, well, here:
>
> http://cvs.apache.org/viewcvs/jakarta-velocity/contrib/temporary/struts-velo
> city/src/java/org/apache/velocity/struts/
>
Seems obvious to me. At least it wasn't sent out, sent back, buried in soft
peat for three months...
Seriously - lets take a good run at this...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - 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 Tim Colson <tc...@cisco.com>.
> Is there any chance I can get that? Has it ever been put in CVS? (Not much
> of a CVS expert - thus the question...)
I had that same question myself a few weeks ago, found them "on display in
the bottom of a locked filing cabinet stuck in a disused lavatory with a
sign on the door saying 'Beware of the Leopard.' " ... err, well, here:
http://cvs.apache.org/viewcvs/jakarta-velocity/contrib/temporary/struts-velo
city/src/java/org/apache/velocity/struts/
Cheers,
Tim
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>