You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Michael Jouravlev <jm...@gmail.com> on 2006/05/04 19:53:25 UTC
Make base Action class a dispatch action
What we has been brought from the stone ages:
* Base Action class does not dispatch events
* DispatchAction and its flavors do, but they do not allow a user to
derive an action class from some another user's base action
What we got now in 1.2.9 and 1.3.1+ :
* ActionDispatcher resolves the inheritance issue, allowing any action
to dispatch events
* EventActionDispatcher makes dispatching an easy and fun task; it
also allows to separate input phase from render phase, at the same
time it allows to trigger event with links (GET), not only with
buttons (POST).
What appears to be a logical next step:
* Stick dispatching features in base Action, thus making all actions
to be dispatch actions.
Benefits:
* ActionDispatcher will not be needed.
* Any action will be able to dispatch events.
* This makes a mind shift, making people think more in terms of events
and independent webresources, kind of like .NET's code-behind.
Minor drawback:
* only one dispatching behavior can be chosen. Considering all job
done before, we how have best-of-breed EventDispatchAction. Its
features (maybe in some modified manner) should be pushed to base
Action class. For those who rely on old-style DispatchAction or
MappingDispatchAction, they will still be available.
So, the proposed feature changes nothing for regular Action users, it
changes nothing for old DispatchAction users, but it makes things a
lot simpler for those who want to switch to event-based paradigm with
as little efforts as possible.
Thoughts? Objections? Suggestions?
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Make base Action class a dispatch action
Posted by Don Brown <do...@gmail.com>.
I like it, although you should probably bring this over to the dev list. :)
Don
On 5/4/06, Michael Jouravlev <jm...@gmail.com> wrote:
> What we has been brought from the stone ages:
>
> * Base Action class does not dispatch events
> * DispatchAction and its flavors do, but they do not allow a user to
> derive an action class from some another user's base action
>
> What we got now in 1.2.9 and 1.3.1+ :
>
> * ActionDispatcher resolves the inheritance issue, allowing any action
> to dispatch events
> * EventActionDispatcher makes dispatching an easy and fun task; it
> also allows to separate input phase from render phase, at the same
> time it allows to trigger event with links (GET), not only with
> buttons (POST).
>
> What appears to be a logical next step:
>
> * Stick dispatching features in base Action, thus making all actions
> to be dispatch actions.
>
> Benefits:
>
> * ActionDispatcher will not be needed.
> * Any action will be able to dispatch events.
> * This makes a mind shift, making people think more in terms of events
> and independent webresources, kind of like .NET's code-behind.
>
> Minor drawback:
>
> * only one dispatching behavior can be chosen. Considering all job
> done before, we how have best-of-breed EventDispatchAction. Its
> features (maybe in some modified manner) should be pushed to base
> Action class. For those who rely on old-style DispatchAction or
> MappingDispatchAction, they will still be available.
>
> So, the proposed feature changes nothing for regular Action users, it
> changes nothing for old DispatchAction users, but it makes things a
> lot simpler for those who want to switch to event-based paradigm with
> as little efforts as possible.
>
> Thoughts? Objections? Suggestions?
>
> Michael.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Make base Action class a dispatch action
Posted by Dave Newton <ne...@pingsite.com>.
Michael Jouravlev wrote:
> * Stick dispatching features in base Action, thus making all actions
> to be dispatch actions.
>
> Minor drawback:
>
> * only one dispatching behavior can be chosen.
>
> Thoughts? Objections? Suggestions?
Works for me, with the following commentary (some of which may be
misguided or plain wrong, as usual ;)
- make the default "no handler" method the standard "execute" method so
current code would actually use the new dispatching stuff w/o change but
could be easily extended to handle multiple dispatches etc. (Did that
make sense?)
- make the dispatching mechanism injectable via a struts config
"dispatchMethod" attribute so you could easily switch between a param,
URL element, etc.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Make base Action class a dispatch action
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
So long as this statement...
"...the proposed feature changes nothing for regular Action users, it
changes nothing for old DispatchAction users, but it makes things a lot
simpler for those who want to switch to event-based paradigm with as
little efforts as possible."
...is true, count me +1. As long as I can take an existing app and have
it work without modification (or with trivial mods at worst), I can't
think of a reason not to do this.
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
On Thu, May 4, 2006 1:53 pm, Michael Jouravlev said:
> What we has been brought from the stone ages:
>
> * Base Action class does not dispatch events
> * DispatchAction and its flavors do, but they do not allow a user to
> derive an action class from some another user's base action
>
> What we got now in 1.2.9 and 1.3.1+ :
>
> * ActionDispatcher resolves the inheritance issue, allowing any action
> to dispatch events
> * EventActionDispatcher makes dispatching an easy and fun task; it
> also allows to separate input phase from render phase, at the same
> time it allows to trigger event with links (GET), not only with
> buttons (POST).
>
> What appears to be a logical next step:
>
> * Stick dispatching features in base Action, thus making all actions
> to be dispatch actions.
>
> Benefits:
>
> * ActionDispatcher will not be needed.
> * Any action will be able to dispatch events.
> * This makes a mind shift, making people think more in terms of events
> and independent webresources, kind of like .NET's code-behind.
>
> Minor drawback:
>
> * only one dispatching behavior can be chosen. Considering all job
> done before, we how have best-of-breed EventDispatchAction. Its
> features (maybe in some modified manner) should be pushed to base
> Action class. For those who rely on old-style DispatchAction or
> MappingDispatchAction, they will still be available.
>
> So, the proposed feature changes nothing for regular Action users, it
> changes nothing for old DispatchAction users, but it makes things a
> lot simpler for those who want to switch to event-based paradigm with
> as little efforts as possible.
>
> Thoughts? Objections? Suggestions?
>
> Michael.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [MOVED] Make base Action class a dispatch action
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I agree with Niall, this is more appropriate to the dev list...
Niall Pemberton wrote:
> I don't see how it could be core for Commands, since Command is part
> of Commons Chain and not Struts and is an interface anyway,
This was my first thought upon reading this too. I think the
interesting question is what 1.3 developers are going to be doing more
often: continuing to use some form of Action, or use generic Commands in
their place (whether a chain or just an individual Command). I would
think the later myself. In that case, I could envision a
DispatchCommand that has the capabilities Michael is talking about.
The bottom line though is I think using Commands is a somewhat different
paradigm all on its own, and maybe the whole dispatch concept doesn't
make as much sense there. I'm not sure I have an opinion either way,
I'm just thinking about this for the first time now :)
In any case, as I've said previously, I don't really see that big a
problem with this... I think it would actually be great if we could some
day have a single Action class that could do it all. I'm not sure
that's feasible, or even a good idea ultimately, but it's a thought. If
as Michael proposed, this can be done without affecting existing code
(i.e., if I extend UberAction instead of Action, it'll work the same,
even though I'm not using dispatch functionality), then that seems like
a reasonable idea to me. I'd want to see it before I checked off the
"cool with me" box though :)
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Make base Action class a dispatch action
Posted by Niall Pemberton <ni...@gmail.com>.
On 5/9/06, Michael Jouravlev <jm...@gmail.com> wrote:
> On 5/9/06, Niall Pemberton <ni...@gmail.com> wrote:
> > On 5/4/06, Michael Jouravlev <jm...@gmail.com> wrote:
> > > What we has been brought from the stone ages:
> > >
> > > * Base Action class does not dispatch events
> > > * DispatchAction and its flavors do, but they do not allow a user to
> > > derive an action class from some another user's base action
> > >
> > > What we got now in 1.2.9 and 1.3.1+ :
> > >
> > > * ActionDispatcher resolves the inheritance issue, allowing any action
> > > to dispatch events
> > > * EventActionDispatcher makes dispatching an easy and fun task; it
> > > also allows to separate input phase from render phase, at the same
> > > time it allows to trigger event with links (GET), not only with
> > > buttons (POST).
> > >
> > > What appears to be a logical next step:
> > >
> > > * Stick dispatching features in base Action, thus making all actions
> > > to be dispatch actions.
> > >
> > > Benefits:
> > >
> > > * ActionDispatcher will not be needed.
> > > * Any action will be able to dispatch events.
> > > * This makes a mind shift, making people think more in terms of events
> > > and independent webresources, kind of like .NET's code-behind.
> > >
> > > Minor drawback:
> > >
> > > * only one dispatching behavior can be chosen. Considering all job
> > > done before, we how have best-of-breed EventDispatchAction. Its
> > > features (maybe in some modified manner) should be pushed to base
> > > Action class. For those who rely on old-style DispatchAction or
> > > MappingDispatchAction, they will still be available.
> > >
> > > So, the proposed feature changes nothing for regular Action users, it
> > > changes nothing for old DispatchAction users, but it makes things a
> > > lot simpler for those who want to switch to event-based paradigm with
> > > as little efforts as possible.
> > >
> > > Thoughts? Objections? Suggestions?
> >
> > Personally I'm against this because IMO it just adds
> > confusion/complexity to the Action class that is unnecessary for users
> > who don't want to use the "dispatch" style.
>
> The idea is to add dispatching features to an action class (and, I
> think, to Command as well) while keeping current apps working. I think
> this is possible. Unless the dispatching mapping is defined, nothing
> would change for a user.
>
> > I also think that the
> > current provision for "dispatch" flavours isn't a real barrier for
> > people to adopt the style that you're promoting here.
>
> Most "flavors" of dispatch action have issues, so while they should
> remain available, I believe that they should be deprecated. If not
> deprecated, their location at "Extras" Gulag is quite appropriate. I
> believe that at this moment SAF1 has one dispatching action
> (EventDispatchAction) that solves most of the issues of DispatchAction
> or LookupDispatchAction while providing more features.
Personally I don't like LookupDispatchAction since it causes the most
problems and seems a convoluted way of doing things. I don't have any
issues with DispatchAction or MappingDispatchAction which seem fairly
reasonable to me - but as I said before though, I don't use them :-)
> > For people not limited/restricted by having to inherit from a "base"
> > action class, they can simply inherit from one of the DispatchAction
> > falvours.
>
> Well, they won't have to do that. Every action will be a dispatching
> action (if needed). This is logical, especially considering that
> according to Front Controller spec, Action has Dispatcher role :) This
> will also allow to debunk the claim that Struts has no notion of
> events ;-)
>
> > For people limited/restricted by having to inherit from a "base"
> > action class, they can use the ActionDispatcher (or
> > EventActionDispatcher) to easily plug in dispatch behaviour.
>
> Instead of using/learning bunch of classes people can have only one class.
>
> > Simply making the code changes you suggest will not shift people's
> > mindset - you would need to document the choices available. IMO
> > documentation is more important than merging the dispatch logic into
> > the Action class and if Action and DispatchAction flavours were better
> > documented you could achieve the same without changing the code at
> > all.
>
> Better documentation will surely help, as well as easier access to
> these features, like having them right in the core instead of in
> Extras module, as well as recommending this approach as a good
> practice. Users prefer "official" recommendations.
>
> > I don't use any of the DispatchAction/ActionDispatcher flavours and am
> > happy with "simple" Actions. If we do document this better I would
> > prefer we didn't promote one style over the other - but simply layout
> > what the choices people have and let them decide.
>
> Niall, do you use separate setup/render and submit actions? Dispatch
> action is basically the same thing, only you have one submit action
> instead of several. Less classes, less mappings, is not it a good
> thing? Maybe your use cases are different...
No I don't - generally I use the same Action for both setup/render and
submit. I have my own "base" Action which I guess is a simplified
dispatch action - it has two methods - one for setup/render and the
other for submit and I use a <hidden> element (with a standard
name/value) on the form to indicate the submit phase. Unlike all the
dispatch code its v. simple, just a few lines and doesn't need any
reflection.
What I haven't done is grouped related functionality (e.g. add
customer, update customer, delete customer) into single Actions and
see little benefit in doing so. I haven't gotten around to it yet but
I'm more likely to stick with this and use the *wildcard*
functionality to reduce the struts-config.xml.
> Considering that it is possible to use Command instead of Action in
> 1.3.x, I agree that dispatching functionality should be either
> external to actions/commands, so both Command and Action could be used
> for dispatch, or should be implemented in the core for both actions
> and commands. Good point.
I don't see how it could be core for Commands, since Command is part
of Commons Chain and not Struts and is an interface anyway,
> I hope that the fact that you (as well as some other committers) do
> not use dispatch actions, will not affect the technical decision on
> this issue. I believe that dispatch actions change the paradigm, and
> allow to develop more resource-oriented webapps in Struts, comparing
> to request-oriented or page-oriented. I like to think of
> Action+ActionForm combo as of a code-behind class.
At this point I haven't really seen a technical argument - seems like
its more a case of having this functionality in the *core* Action
class as a way of promoting a particular approach. From my point of
view I think it makes Action more complex to understand, for people
not interested in that approach.
> I think that having one dispatch action *is* better than a bunch of
> action classes, and actually I was hoping on promoting this approach.
You mean you haven't been so far?
Sorry couldn't resist ;-)
> Anyway, I'll try to put together some [not too passionate] docs and
> examples first :)
>
> So, to recap:
>
> * I will create drafts of docs and samples to promote dispatch actions
> as a best practice (ok, ok, as a good practice)
> * I will research the better and simpler way of providing dispatch
> functionality,whether by implementing it in the core or by using
> ActionDispatcher class.
Probably we should have moved this to the dev list for discussion,
since that would be a better place to canvas for opinions - it might
get missed here on user.
Niall
> Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Please help with indexed fields
Posted by Sudha Kona <su...@yahoo.com>.
Hi,
I am trying to create text fields dynamically in a form at the request time. I need to have two text fields in a table row and an "ADD" button. When the user clicks on "ADD" button, the form should refresh and shows another row with two text fields and so on. In case if I have entered some data into any of these text fields, the data should be prepopulated when the form refreshes. I have "SUBMIT" button, when clicked, form action will be performed. I am using DynaValidatorActionForm here. I am stuck up with this problem for the last two days. Can anyone please send me a sample of code for JSP and struts-config.xml?
Thanks,
Sudha
Michael Jouravlev <jm...@gmail.com> wrote: On 5/9/06, Niall Pemberton wrote:
> On 5/4/06, Michael Jouravlev wrote:
> > What we has been brought from the stone ages:
> >
> > * Base Action class does not dispatch events
> > * DispatchAction and its flavors do, but they do not allow a user to
> > derive an action class from some another user's base action
> >
> > What we got now in 1.2.9 and 1.3.1+ :
> >
> > * ActionDispatcher resolves the inheritance issue, allowing any action
> > to dispatch events
> > * EventActionDispatcher makes dispatching an easy and fun task; it
> > also allows to separate input phase from render phase, at the same
> > time it allows to trigger event with links (GET), not only with
> > buttons (POST).
> >
> > What appears to be a logical next step:
> >
> > * Stick dispatching features in base Action, thus making all actions
> > to be dispatch actions.
> >
> > Benefits:
> >
> > * ActionDispatcher will not be needed.
> > * Any action will be able to dispatch events.
> > * This makes a mind shift, making people think more in terms of events
> > and independent webresources, kind of like .NET's code-behind.
> >
> > Minor drawback:
> >
> > * only one dispatching behavior can be chosen. Considering all job
> > done before, we how have best-of-breed EventDispatchAction. Its
> > features (maybe in some modified manner) should be pushed to base
> > Action class. For those who rely on old-style DispatchAction or
> > MappingDispatchAction, they will still be available.
> >
> > So, the proposed feature changes nothing for regular Action users, it
> > changes nothing for old DispatchAction users, but it makes things a
> > lot simpler for those who want to switch to event-based paradigm with
> > as little efforts as possible.
> >
> > Thoughts? Objections? Suggestions?
>
> Personally I'm against this because IMO it just adds
> confusion/complexity to the Action class that is unnecessary for users
> who don't want to use the "dispatch" style.
The idea is to add dispatching features to an action class (and, I
think, to Command as well) while keeping current apps working. I think
this is possible. Unless the dispatching mapping is defined, nothing
would change for a user.
> I also think that the
> current provision for "dispatch" flavours isn't a real barrier for
> people to adopt the style that you're promoting here.
Most "flavors" of dispatch action have issues, so while they should
remain available, I believe that they should be deprecated. If not
deprecated, their location at "Extras" Gulag is quite appropriate. I
believe that at this moment SAF1 has one dispatching action
(EventDispatchAction) that solves most of the issues of DispatchAction
or LookupDispatchAction while providing more features.
> For people not limited/restricted by having to inherit from a "base"
> action class, they can simply inherit from one of the DispatchAction
> falvours.
Well, they won't have to do that. Every action will be a dispatching
action (if needed). This is logical, especially considering that
according to Front Controller spec, Action has Dispatcher role :) This
will also allow to debunk the claim that Struts has no notion of
events ;-)
> For people limited/restricted by having to inherit from a "base"
> action class, they can use the ActionDispatcher (or
> EventActionDispatcher) to easily plug in dispatch behaviour.
Instead of using/learning bunch of classes people can have only one class.
> Simply making the code changes you suggest will not shift people's
> mindset - you would need to document the choices available. IMO
> documentation is more important than merging the dispatch logic into
> the Action class and if Action and DispatchAction flavours were better
> documented you could achieve the same without changing the code at
> all.
Better documentation will surely help, as well as easier access to
these features, like having them right in the core instead of in
Extras module, as well as recommending this approach as a good
practice. Users prefer "official" recommendations.
> I don't use any of the DispatchAction/ActionDispatcher flavours and am
> happy with "simple" Actions. If we do document this better I would
> prefer we didn't promote one style over the other - but simply layout
> what the choices people have and let them decide.
Niall, do you use separate setup/render and submit actions? Dispatch
action is basically the same thing, only you have one submit action
instead of several. Less classes, less mappings, is not it a good
thing? Maybe your use cases are different...
Considering that it is possible to use Command instead of Action in
1.3.x, I agree that dispatching functionality should be either
external to actions/commands, so both Command and Action could be used
for dispatch, or should be implemented in the core for both actions
and commands. Good point.
I hope that the fact that you (as well as some other committers) do
not use dispatch actions, will not affect the technical decision on
this issue. I believe that dispatch actions change the paradigm, and
allow to develop more resource-oriented webapps in Struts, comparing
to request-oriented or page-oriented. I like to think of
Action+ActionForm combo as of a code-behind class.
I think that having one dispatch action *is* better than a bunch of
action classes, and actually I was hoping on promoting this approach.
Anyway, I'll try to put together some [not too passionate] docs and
examples first :)
So, to recap:
* I will create drafts of docs and samples to promote dispatch actions
as a best practice (ok, ok, as a good practice)
* I will research the better and simpler way of providing dispatch
functionality,whether by implementing it in the core or by using
ActionDispatcher class.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
---------------------------------
New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.
Re: Make base Action class a dispatch action
Posted by Michael Jouravlev <jm...@gmail.com>.
On 5/9/06, Niall Pemberton <ni...@gmail.com> wrote:
> On 5/4/06, Michael Jouravlev <jm...@gmail.com> wrote:
> > What we has been brought from the stone ages:
> >
> > * Base Action class does not dispatch events
> > * DispatchAction and its flavors do, but they do not allow a user to
> > derive an action class from some another user's base action
> >
> > What we got now in 1.2.9 and 1.3.1+ :
> >
> > * ActionDispatcher resolves the inheritance issue, allowing any action
> > to dispatch events
> > * EventActionDispatcher makes dispatching an easy and fun task; it
> > also allows to separate input phase from render phase, at the same
> > time it allows to trigger event with links (GET), not only with
> > buttons (POST).
> >
> > What appears to be a logical next step:
> >
> > * Stick dispatching features in base Action, thus making all actions
> > to be dispatch actions.
> >
> > Benefits:
> >
> > * ActionDispatcher will not be needed.
> > * Any action will be able to dispatch events.
> > * This makes a mind shift, making people think more in terms of events
> > and independent webresources, kind of like .NET's code-behind.
> >
> > Minor drawback:
> >
> > * only one dispatching behavior can be chosen. Considering all job
> > done before, we how have best-of-breed EventDispatchAction. Its
> > features (maybe in some modified manner) should be pushed to base
> > Action class. For those who rely on old-style DispatchAction or
> > MappingDispatchAction, they will still be available.
> >
> > So, the proposed feature changes nothing for regular Action users, it
> > changes nothing for old DispatchAction users, but it makes things a
> > lot simpler for those who want to switch to event-based paradigm with
> > as little efforts as possible.
> >
> > Thoughts? Objections? Suggestions?
>
> Personally I'm against this because IMO it just adds
> confusion/complexity to the Action class that is unnecessary for users
> who don't want to use the "dispatch" style.
The idea is to add dispatching features to an action class (and, I
think, to Command as well) while keeping current apps working. I think
this is possible. Unless the dispatching mapping is defined, nothing
would change for a user.
> I also think that the
> current provision for "dispatch" flavours isn't a real barrier for
> people to adopt the style that you're promoting here.
Most "flavors" of dispatch action have issues, so while they should
remain available, I believe that they should be deprecated. If not
deprecated, their location at "Extras" Gulag is quite appropriate. I
believe that at this moment SAF1 has one dispatching action
(EventDispatchAction) that solves most of the issues of DispatchAction
or LookupDispatchAction while providing more features.
> For people not limited/restricted by having to inherit from a "base"
> action class, they can simply inherit from one of the DispatchAction
> falvours.
Well, they won't have to do that. Every action will be a dispatching
action (if needed). This is logical, especially considering that
according to Front Controller spec, Action has Dispatcher role :) This
will also allow to debunk the claim that Struts has no notion of
events ;-)
> For people limited/restricted by having to inherit from a "base"
> action class, they can use the ActionDispatcher (or
> EventActionDispatcher) to easily plug in dispatch behaviour.
Instead of using/learning bunch of classes people can have only one class.
> Simply making the code changes you suggest will not shift people's
> mindset - you would need to document the choices available. IMO
> documentation is more important than merging the dispatch logic into
> the Action class and if Action and DispatchAction flavours were better
> documented you could achieve the same without changing the code at
> all.
Better documentation will surely help, as well as easier access to
these features, like having them right in the core instead of in
Extras module, as well as recommending this approach as a good
practice. Users prefer "official" recommendations.
> I don't use any of the DispatchAction/ActionDispatcher flavours and am
> happy with "simple" Actions. If we do document this better I would
> prefer we didn't promote one style over the other - but simply layout
> what the choices people have and let them decide.
Niall, do you use separate setup/render and submit actions? Dispatch
action is basically the same thing, only you have one submit action
instead of several. Less classes, less mappings, is not it a good
thing? Maybe your use cases are different...
Considering that it is possible to use Command instead of Action in
1.3.x, I agree that dispatching functionality should be either
external to actions/commands, so both Command and Action could be used
for dispatch, or should be implemented in the core for both actions
and commands. Good point.
I hope that the fact that you (as well as some other committers) do
not use dispatch actions, will not affect the technical decision on
this issue. I believe that dispatch actions change the paradigm, and
allow to develop more resource-oriented webapps in Struts, comparing
to request-oriented or page-oriented. I like to think of
Action+ActionForm combo as of a code-behind class.
I think that having one dispatch action *is* better than a bunch of
action classes, and actually I was hoping on promoting this approach.
Anyway, I'll try to put together some [not too passionate] docs and
examples first :)
So, to recap:
* I will create drafts of docs and samples to promote dispatch actions
as a best practice (ok, ok, as a good practice)
* I will research the better and simpler way of providing dispatch
functionality,whether by implementing it in the core or by using
ActionDispatcher class.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Make base Action class a dispatch action
Posted by Dave Newton <ne...@pingsite.com>.
Niall Pemberton wrote:
> Personally I'm against this because IMO it just adds
> confusion/complexity to the Action class that is unnecessary for users
> who don't want to use the "dispatch" style.
Not if you use my idea of making the 'execute' method the default dispatch.
Of course, don't name one of your params 'execute' ;)
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Make base Action class a dispatch action
Posted by Dakota Jack <da...@gmail.com>.
I agree completely with Niall on this one. I cannot believe that the
basic action class could conceivably be considered to carry this
overhead.
On 5/9/06, Niall Pemberton <ni...@gmail.com> wrote:
> On 5/4/06, Michael Jouravlev <jm...@gmail.com> wrote:
> > What we has been brought from the stone ages:
> >
> > * Base Action class does not dispatch events
> > * DispatchAction and its flavors do, but they do not allow a user to
> > derive an action class from some another user's base action
> >
> > What we got now in 1.2.9 and 1.3.1+ :
> >
> > * ActionDispatcher resolves the inheritance issue, allowing any action
> > to dispatch events
> > * EventActionDispatcher makes dispatching an easy and fun task; it
> > also allows to separate input phase from render phase, at the same
> > time it allows to trigger event with links (GET), not only with
> > buttons (POST).
> >
> > What appears to be a logical next step:
> >
> > * Stick dispatching features in base Action, thus making all actions
> > to be dispatch actions.
> >
> > Benefits:
> >
> > * ActionDispatcher will not be needed.
> > * Any action will be able to dispatch events.
> > * This makes a mind shift, making people think more in terms of events
> > and independent webresources, kind of like .NET's code-behind.
> >
> > Minor drawback:
> >
> > * only one dispatching behavior can be chosen. Considering all job
> > done before, we how have best-of-breed EventDispatchAction. Its
> > features (maybe in some modified manner) should be pushed to base
> > Action class. For those who rely on old-style DispatchAction or
> > MappingDispatchAction, they will still be available.
> >
> > So, the proposed feature changes nothing for regular Action users, it
> > changes nothing for old DispatchAction users, but it makes things a
> > lot simpler for those who want to switch to event-based paradigm with
> > as little efforts as possible.
> >
> > Thoughts? Objections? Suggestions?
>
> Personally I'm against this because IMO it just adds
> confusion/complexity to the Action class that is unnecessary for users
> who don't want to use the "dispatch" style. I also think that the
> current provision for "dispatch" flavours isn't a real barrier for
> people to adopt the style that you're promoting here.
>
> For people not limited/restricted by having to inherit from a "base"
> action class, they can simply inherit from one of the DispatchAction
> falvours.
>
> For people limited/restricted by having to inherit from a "base"
> action class, they can use the ActionDispatcher (or
> EventActionDispatcher) to easily plug in dispatch behaviour.
>
> Simply making the code changes you suggest will not shift people's
> mindset - you would need to document the choices available. IMO
> documentation is more important than merging the dispatch logic into
> the Action class and if Action and DispatchAction flavours were better
> documented you could achieve the same without changing the code at
> all.
>
> I don't use any of the DispatchAction/ActionDispatcher flavours and am
> happy with "simple" Actions. If we do document this better I would
> prefer we didn't promote one style over the other - but simply layout
> what the choices people have and let them decide.
>
> Niall
>
> > Michael.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Make base Action class a dispatch action
Posted by Niall Pemberton <ni...@gmail.com>.
On 5/4/06, Michael Jouravlev <jm...@gmail.com> wrote:
> What we has been brought from the stone ages:
>
> * Base Action class does not dispatch events
> * DispatchAction and its flavors do, but they do not allow a user to
> derive an action class from some another user's base action
>
> What we got now in 1.2.9 and 1.3.1+ :
>
> * ActionDispatcher resolves the inheritance issue, allowing any action
> to dispatch events
> * EventActionDispatcher makes dispatching an easy and fun task; it
> also allows to separate input phase from render phase, at the same
> time it allows to trigger event with links (GET), not only with
> buttons (POST).
>
> What appears to be a logical next step:
>
> * Stick dispatching features in base Action, thus making all actions
> to be dispatch actions.
>
> Benefits:
>
> * ActionDispatcher will not be needed.
> * Any action will be able to dispatch events.
> * This makes a mind shift, making people think more in terms of events
> and independent webresources, kind of like .NET's code-behind.
>
> Minor drawback:
>
> * only one dispatching behavior can be chosen. Considering all job
> done before, we how have best-of-breed EventDispatchAction. Its
> features (maybe in some modified manner) should be pushed to base
> Action class. For those who rely on old-style DispatchAction or
> MappingDispatchAction, they will still be available.
>
> So, the proposed feature changes nothing for regular Action users, it
> changes nothing for old DispatchAction users, but it makes things a
> lot simpler for those who want to switch to event-based paradigm with
> as little efforts as possible.
>
> Thoughts? Objections? Suggestions?
Personally I'm against this because IMO it just adds
confusion/complexity to the Action class that is unnecessary for users
who don't want to use the "dispatch" style. I also think that the
current provision for "dispatch" flavours isn't a real barrier for
people to adopt the style that you're promoting here.
For people not limited/restricted by having to inherit from a "base"
action class, they can simply inherit from one of the DispatchAction
falvours.
For people limited/restricted by having to inherit from a "base"
action class, they can use the ActionDispatcher (or
EventActionDispatcher) to easily plug in dispatch behaviour.
Simply making the code changes you suggest will not shift people's
mindset - you would need to document the choices available. IMO
documentation is more important than merging the dispatch logic into
the Action class and if Action and DispatchAction flavours were better
documented you could achieve the same without changing the code at
all.
I don't use any of the DispatchAction/ActionDispatcher flavours and am
happy with "simple" Actions. If we do document this better I would
prefer we didn't promote one style over the other - but simply layout
what the choices people have and let them decide.
Niall
> Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org