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]>
