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" <[EMAIL PROTECTED]> wrote: >> -----Original Message----- >> From: Ted Husted [mailto:[EMAIL PROTECTED]] >> 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>