struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Husted <>
Subject Re: Custom Actions? (was RE: Benefits of Dynaforms)
Date Thu, 28 Nov 2002 23:53:24 GMT
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.


11/27/2002 9:31:50 PM, John Yu <> wrote:

>So, with respect to the "routing instructions", you create a 
>abstraction ("success", "failure", etc) describing the exit path 
of the 
>business process. Gotcha.
>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 
>>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 
>>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 
>>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, 
>>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 
>>implementation details. In this case, the implementation detail 
>>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 
>>partner insisted that we do this, and in retrospect, I've come 
>>agree with the idea.
>>Conceptually, Struts is simply the presentation-tier controller.
>>Ideally, there should also be a controller that lives above 
>>that could be compatible with multiple platforms (or even 
>>frameworks). Like message resources, the application controller
>>can work in terms of simple logical names and let lower 
>>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 
>>controller configuration. But something we all keep wishing for 
>>a more sophisticated workflow controller that would live above
>>Struts. The only responsibility of the struts-config would then 
>>to match the control tokens ("success", "failure", 
>>with the appropriate URIs.
>>So, from my perspective, Struts "knows" which tokens my
>>application controller expects. But my application controller 
>>no clue that Struts even exists.
>>"Coincidentally", my (conceptual) application controller uses 
>>same design paradigm as the struts-config, just like it uses the
>>same design paradigm for messaging -- but only because great 
>>think alike =:0)
>>11/26/2002 8:59:49 PM, John Yu <> wrote:
>> >If the Action is truly generic, how do you avoid returning
>> >presentation-specific information in the result objects? e.g. 
>> >instruction would be something like a forward name . (Am I
>> >
>> >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" 
>>an Action
>> >and part of the presentation-layer? (Consider: how to reuse 
>> >process, say in Velocity, and still make use of its result
>> >
>> >Have I missed something?
>> >--
>> >John
>> >
>> >
>> >>Basically, I'm putting my business tier behind a facade, and
>> >>the ActionMapping decorator to tell the standard Action which
>> >>operation to invoke. The facade provides a consistent 
>> >>and minimizes what the Struts tier needs to know about each
>> >>operation.
>> >>
>> >>-Ted.
>> >>
>> >>11/22/2002 9:47:43 AM, Andre Beskrowni <>
>> >>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 
>> >>some sort of
>> >> >database operation: displaying, creating, updating, or
>> >>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 
>> >>could you
>> >> >elaborate on your process?
>> >> >
>> >> >thanks,
>> >> >
>> >> >ab
>> >> >
>> >
>> >--
>> >John Yu                       Scioworks Technologies
>> >e:         w: +(65) 873 5989
>> >w: m: +(65) 9782 9610
>> >
>> >
>> >--
>> >To unsubscribe, e-mail:   <mailto:struts-dev-
>> >For additional commands, e-mail: <mailto:struts-dev-
>> >
>> >
>>To unsubscribe, e-mail:   <mailto:struts-dev->
>>For additional commands, e-mail: <mailto:struts-dev->
>John Yu                       Scioworks Technologies
>e:         w: +(65) 873 5989
>w:   m: +(65) 9782 9610
>Scioworks Camino - "Don't develop Struts Apps without it!"
>Copyright (c) 2002 John Yu/Scioworks Technologies. All rights 
>To unsubscribe, e-mail:   <mailto:struts-dev->
>For additional commands, e-mail: <mailto:struts-dev->

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message