So, with respect to the "routing instructions", you create a common abstraction ("success", "failure", etc) describing the exit path of the business process. Gotcha.
Thanks.
--
John
At 06:50 pm 27-11-2002, you wrote:
The Actions are generic, but the ActionMappings are not =:0) The ActionMapping passes command tokens to the standard Action so that it knows which business process to invoke.The business facade returns a result object with can carry messages, data, and/or dispatch advice. The messages are Struts-compatible, but mainly because the Struts messsaging API is based on the standard java.util package. So while I'm passing back a message token and several runtime parameters to be merged against the Application Resources, I'm not really using the Struts messaging. I'm using standard messaging, which Struts *also* uses. The data comes back as a collection or as a single form. By default, the Action places collections in request scope under a standard token. By default, if there is an ActionForm in play, the Action repopulates it when a single-form is returned. The very versatile BeanUtils.copyProperties makes it very easy to "roundtrip" ActionForms and typed JavaBeans. In the rare case when there is any dispatch advice, it generally comes back as a token (e.g. "success", "failure"). This is a continuation of what we do with the messages. We give them names to represent the general idea and let other components fill in the implementation details. In this case, the implementation detail is a URI. But the business facade doesn't know or care about that. Initially, I wasn't keen on the last bit myself. But I developed portions of this to work with the Adalon GUI by Synthis. My coding partner insisted that we do this, and in retrospect, I've come to agree with the idea. Conceptually, Struts is simply the presentation-tier controller. Ideally, there should also be a controller that lives above Struts that could be compatible with multiple platforms (or even multiple frameworks). Like message resources, the application controller can work in terms of simple logical names and let lower components fill in the implementation details. In practice, Struts provides many design artifacts that could exist at a higher level. This is a Good Thing, since it lets simple applications use them directly and sophisticated applications use them as adapters. For the most part, I'm still using the struts-config as my primary controller configuration. But something we all keep wishing for is a more sophisticated workflow controller that would live above Struts. The only responsibility of the struts-config would then be to match the control tokens ("success", "failure", "glockenspiel") with the appropriate URIs. So, from my perspective, Struts "knows" which tokens my application controller expects. But my application controller has no clue that Struts even exists. "Coincidentally", my (conceptual) application controller uses the same design paradigm as the struts-config, just like it uses the same design paradigm for messaging -- but only because great minds think alike =:0) -Ted. 11/26/2002 8:59:49 PM, John Yu <[EMAIL PROTECTED]> wrote: >If the Action is truly generic, how do you avoid returning >presentation-specific information in the result objects? e.g. A routing >instruction would be something like a forward name . (Am I correct?) > >If so, the business process "knows" about configuration in the >struts-config.xml. Doesn't the presentation/business-tier boundary become >blur? Isn't the business process now becoming an "extension" of an Action >and part of the presentation-layer? (Consider: how to reuse this business >process, say in Velocity, and still make use of its result object?) > >Have I missed something? >-- >John > > >>Basically, I'm putting my business tier behind a facade, and using >>the ActionMapping decorator to tell the standard Action which >>operation to invoke. The facade provides a consistent interface >>and minimizes what the Struts tier needs to know about each >>operation. >> >>-Ted. >> >>11/22/2002 9:47:43 AM, Andre Beskrowni <[EMAIL PROTECTED]> >>wrote: >> >> >ok, this one sentence in ted's post caught my eye: >> > >> >> I rarely write custom Actions any more. >> > >> >whoah. how is this possible? most of our web pages represent >>some sort of >> >database operation: displaying, creating, updating, or deleting. >>i can see >> >how you can minimize the amount of code that would vary in >>individual Action >> >classes, but i don't see how could eliminate the need for >>subclassing >> >altogether. maybe i'm just completely misunderstanding here. >>could you >> >elaborate on your process? >> > >> >thanks, >> > >> >ab >> > > >-- >John Yu Scioworks Technologies >e: [EMAIL PROTECTED] w: +(65) 873 5989 >w: http://www.scioworks.com m: +(65) 9782 9610 > > >-- >To unsubscribe, e-mail: <mailto:struts-dev- [EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:struts-dev- [EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- John Yu Scioworks Technologies e: [EMAIL PROTECTED] w: +(65) 873 5989 w: http://www.scioworks.com m: +(65) 9782 9610 Scioworks Camino - "Don't develop Struts Apps without it!" Copyright (c) 2002 John Yu/Scioworks Technologies. All rights reserved. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
