Re: RE: servletMapping field in ActionServlet (1.0.2) (long)

[Ted Husted <hu...@apache.org>]

IMHO, the best way to use XML is as a generator/decorator for 
objects. One decoration might be to pass a script to a Java class 
for processing, but framing conditions in a XML files seems to 
step over the line to me. 

Right now, a very good way to test preconditions is through a 
component like the Struts validator. It plugs into the ActionForm 
and confirms that whatever properties are needed are ready, 
willing and agle to go. 

In the normal course, an Action should not need to interact with 
the request or session at all. The ActionForm should encapsulate 
whatever input is needed. 

The routing instructions in Struts are the ActionForwards. The 
Actions can select a destiation using a logical name, and that 
name is mapped to a destination in the configuration. 

For the most part, I just validate the ActionForms, create a data 
transfer object, and pass it all up to the business tier for 
handling. The business object passes back a response that the 
Action analyzes. 

Where someone might be able to plug scripts into Struts would be 
as an alternative to writing Java code. A standard Action could 
evalulate the script and return a result, so the rest of the 
framework wouldn't know that the script exists.

You might embed the script in a XML file, the way the Struts 
validation embed a Javascript in its configuration. But might be 
better to go with a separate configuration file for something like 
that, so it could be used with or without Struts.

-Ted.


11/23/2002 12:19:54 PM, "Nelson, Laird" <La...@FMR.COM> 
wrote:

>> -----Original Message-----
>> From: Ted Husted [mailto:husted@apache.org]
>> What you might be driving at is the ability to pass some type 
of 
>> scripting statement to an Action, that it could then interpret 
at 
>> runtime. Another place to put something like this is the 
parameter 
>> property. 
>
>That's exactly what I'm driving at.  Maybe BSF/BeanShell is a 
good match
>here, as I think about it, as I'm not a huge fan of doing 
scripting with XML
>syntax.
>
>> I sometimes do things like have my Actions look at their 
>> ActionForwards to decide whether do some things (like look for 
a 
>> cancel request or a missing token).
>
>Ditto.
>
>The motivation behind this idea was my thinking along these 
lines:
>
>There's usually a pretty small set of "real" destinations in a 
webapp.  By
>"real", I mean a destination that either brings the user to a 
page that's
>interesting to him, or that completes a process.  Most of the 
destinations
>within webapps that I've seen or had to design are state 
augmentors and
>traffic cops.
>
>Think of a hypothetical RegistrationAction.  It has a set of 
preconditions,
>let's say, for it to do its job.  In order for it to work and not 
to throw
>an error, it needs to find a username, password, first name, last 
name and
>zip code.  If it is ever invoked without any of these things it 
simply will
>not fire (i.e. will not contact the relevant business object in 
the model
>tier to store the registration information).
>
>OK; in this silly situation, right now, all Struts can say in its
>struts-config.xml out of the box is something like "when I get a 
request for
>/registration.do, route to the RegistrationAction" (let's leave 
aside custom
>ActionMapping implementations and the like for a moment):
>
>  <action path="/registration"
>          type="RegistrationAction/>
>
>This means that RegistrationAction can receive requests that may 
or may not
>have the additional state it needs in order to satisfy its 
preconditions.
>This also means that either (a) RegistrationAction or (b) some 
other Action
>that will eventually forward to it needs to check the
>request/session/servlet context to evaluate whether those bits of 
state--the
>username, password, etc.--are present, and consequently to 
evaluate whether
>the RegistrationAction can be safely invoked.  To me, this kind 
of thing is
>routing logic.  Since Struts already locates its routing logic in
>struts-config.xml (with <action-mappings>, <forwards>, <form-
beans> and the
>like), it would be really cool IMHO if there were a facility to 
locate
>*this* kind of routing logic in there as well:
>
>  <action path="/registration">
>    <routing-logic type="BSF:bsh"> <!-- thinking out loud here 
-->
>      final String userName = request.getParameter("userName");
>      // ...and so on...
>      if (userName != null) {
>        // type variable would be exposed by BSF
>        type = RegistrationAction.class;
>      } else {
>        type = SomeOtherAction.class;
>      }
>    </routing-logic>
>  </action>
>
>Voila.  Now this kind of routing logic doesn't have to live in 
any Action.
>
>(Your point is taken about the inability to use existing 
<logic:present>
>tags and the like here; you are exactly right in that what I'm 
driving at is
>to save a script that would be evaluated at runtime (possibly 
having been
>compiled first).  Squint your eyes and blur the silly syntax I 
invented
>above.  :-))
>
>I always find that a good {pulls number out of air} 40% or so of 
my Actions
>are devoted to really doing this kind of routing logic based on 
the
>presence/absence/pattern matching of various request/session 
attributes.
>Although there's of course nothing architecturally or technically 
wrong with
>this (it's controller logic happening in the controller layer--no 
MVC
>violations here), it would be neat to put it all in the same 
place, so that
>people just know that all the routing logic is in the struts-
config file,
>and not buried in the code somewhere.  Then you would also know 
that all
>remaining Actions would truly be business object invokers, and 
not part-time
>traffic cops.  :-)
>
>The drawback, of course, would be that the struts-config.xml 
would become
>more like a hairy piece of code than a configuration file.
>
>Anyhow, food for thought.
>
>Cheers,
>Laird
>
>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>