Yes, but only if something unusual happens. In the normal course, the struts-config routings fall through.
The core idea is that the abstractions belong to *my* application interface. The struts-config is implementing these abstractions on behalf of the greater application. Just as the language abstraction in the Application Resources do not belong to Struts, but are a resource that Struts can share with others. =Ted. 11/27/2002 9:31:50 PM, John Yu <[EMAIL PROTECTED]> wrote: >Ted, > >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:struts-dev- [EMAIL PROTECTED]> >>For additional commands, e-mail: <mailto:struts-dev- [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: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]>