You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Andre Beskrowni <AB...@axeda.com> on 2002/11/22 15:47:43 UTC
Custom Actions? (was RE: Benefits of Dynaforms)
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
> Ideally, a framework like Struts should just be passing gestures
> and data back and forth between the presentation pages and
> business tier. IMHO, doing any "real" programming in Struts is an
> engineering compromise. Architecturally, we should be trying to
> help developers avoid as many "necessary evils" as possible.
> DynaBeans serve that purpose by making it possible to avoid
> creating and maintaining yet-another Java class, which, in
> practice, often encroaches on the business tier.
>
> Before DynaBeans, that practice was unavoidable (or at least
> caused greater evils). With DynaBeans, there is a real possibility
> that you could code the Struts portion of an application entirely
> through XML configuration files, and keep all the "real
> programming" on the business tier.
>
> Here's another kicker: Components like the Validator aren't just
> for the web tier. You could also be using the Commons Validator in
> the business tier, which opens the door to a common Validator
> configuration shared by Struts and the business tier.
>
> DynaBeans also have the potential of being the "missing buffer" we
> need for data-entry. What about a DynaBean class that included a
> "shadow" String field with every dynamic property? (All we need is
> another map.) If we integrated a DynaBeanBuffer subclass with the
> Validator, we could then declare field-level validations for our
> properties. A validate method on the DynaBean could check each of
> its buffers, and transfer the datea if validation passed, but
> raise a flag if it didn't. We could then finally use the same bean
> on the Web tier as we do on the business tier. This sort of thing
> is a bear to code with conventional JavaBean, but might be worth
> doing with something like the DynaBean.
>
> -Ted.
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Custom Actions? (was RE: Benefits of Dynaforms)
Posted by Ted Husted <hu...@apache.org>.
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 <jo...@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 <jo...@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 <AB...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Custom Actions? (was RE: Benefits of Dynaforms)
Posted by John Yu <jo...@scioworks.com>.
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 <jo...@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 <AB...@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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Custom Actions? (was RE: Benefits of Dynaforms)
Posted by Ted Husted <hu...@apache.org>.
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 <jo...@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 <AB...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Custom Actions? (was RE: Benefits of Dynaforms)
Posted by John Yu <jo...@scioworks.com>.
At 04:40 am 23-11-2002, you wrote:
>The idea behind a Struts Action is that it suppose to give you a
>place to call your business logic components. Rather than call
>various business processes through a subclass, I continue the
>decorator pattern by declaring the process to call as part of the
>ActionMapping.
>
>I then use a standard Action which automatically populates the
>designed business bean and invokes the business process. The
>business process returns a specialized result object that the
>standard Action analyzes. The result object has properties that
>can return messsages, data, and/or new routing instructions to the
>Action.
Ted,
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 <AB...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Custom Actions? (was RE: Benefits of Dynaforms)
Posted by Ted Husted <hu...@apache.org>.
The idea behind a Struts Action is that it suppose to give you a
place to call your business logic components. Rather than call
various business processes through a subclass, I continue the
decorator pattern by declaring the process to call as part of the
ActionMapping.
I then use a standard Action which automatically populates the
designed business bean and invokes the business process. The
business process returns a specialized result object that the
standard Action analyzes. The result object has properties that
can return messsages, data, and/or new routing instructions to the
Action.
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 <AB...@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
>
>> Ideally, a framework like Struts should just be passing
gestures
>> and data back and forth between the presentation pages and
>> business tier. IMHO, doing any "real" programming in Struts is
an
>> engineering compromise. Architecturally, we should be trying to
>> help developers avoid as many "necessary evils" as possible.
>> DynaBeans serve that purpose by making it possible to avoid
>> creating and maintaining yet-another Java class, which, in
>> practice, often encroaches on the business tier.
>>
>> Before DynaBeans, that practice was unavoidable (or at least
>> caused greater evils). With DynaBeans, there is a real
possibility
>> that you could code the Struts portion of an application
entirely
>> through XML configuration files, and keep all the "real
>> programming" on the business tier.
>>
>> Here's another kicker: Components like the Validator aren't
just
>> for the web tier. You could also be using the Commons Validator
in
>> the business tier, which opens the door to a common Validator
>> configuration shared by Struts and the business tier.
>>
>> DynaBeans also have the potential of being the "missing
buffer" we
>> need for data-entry. What about a DynaBean class that included
a
>> "shadow" String field with every dynamic property? (All we need
is
>> another map.) If we integrated a DynaBeanBuffer subclass with
the
>> Validator, we could then declare field-level validations for
our
>> properties. A validate method on the DynaBean could check each
of
>> its buffers, and transfer the datea if validation passed, but
>> raise a flag if it didn't. We could then finally use the same
bean
>> on the Web tier as we do on the business tier. This sort of
thing
>> is a bear to code with conventional JavaBean, but might be
worth
>> doing with something like the DynaBean.
>>
>> -Ted.
>>
>>
>>
>>
>> --
>> To unsubscribe, e-mail:
><ma...@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>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>