struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Husted <hus...@apache.org>
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.

=Ted.


11/27/2002 9:31:50 PM, John Yu <john@scioworks.com> 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 <john@scioworks.com> 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 <ABeskrowni@axeda.com>
>> >>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: john@scioworks.com         w: +(65) 873 5989
>> >w: http://www.scioworks.com m: +(65) 9782 9610
>> >
>> >
>> >--
>> >To unsubscribe, e-mail:   <mailto:struts-dev-
>>unsubscribe@jakarta.apache.org>
>> >For additional commands, e-mail: <mailto:struts-dev-
>>help@jakarta.apache.org>
>> >
>> >
>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail:   <mailto:struts-dev-
unsubscribe@jakarta.apache.org>
>>For additional commands, e-mail: <mailto:struts-dev-
help@jakarta.apache.org>
>
>-- 
>John Yu                       Scioworks Technologies
>e: john@scioworks.com         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-
unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:struts-dev-
help@jakarta.apache.org>
>
>




--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message