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