On 6/28/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:
I haven't read Michaels latest write up, so I don't know if its
substantially different, but last time I looked the only reason for
integrating the "dispatch" style into Action was (IMO) to encourage
its use.
If thats still true then my opinion is unchanged:
http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2
* Having dispatch stuff in Action will encourage using this pattern, I
have no doubt about that.
* Events/hadnlers definition becomes first-class element of action mapping.
* Events/hadnlers can be defined in a clean well-documented fashion.
* And after all, It does not hurt anywone. Really. :-)
http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2
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.
Those who do not want to use it will just skip a chapter in the
manual. Nothing else will affect them. The only visible part is
event/handler mapping and they won't see it if they do not use it.
http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2
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.
I think if this approach were more official people would be more
inclined to use it.
http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2
Simply making the code changes you suggest will not shift
people's mindset - you would need to document the choices
available.
I will do my best to document it, that's for sure.
http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2
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.
The code in action would be cleaner, the event mapping would be clean
and visible.
http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2
I don't use any of the DispatchAction/ActionDispatcher flavours
and am happy with "simple" Actions.
Then you won't even notice the change. Really, it does not affect you
or anyone else who does not use this style.
I am preparing an updated documentation on actions in Wiki. It already
saw like 40 updates and will see even more :) I want to build the
solid base about how common use cases are handled. I will do my best
not to promote one style over the other.
I also think that the concrete Action class tied to the servlet API is
legacy
Then why do you care about me enhancing it?! ;-)
and that if you want to inovate then the effort is better spent
focusing on the support for CoR/CoC in Struts 1.3 and the Command
interface (Commons Chain 1.1 even has a DispatchCommand :-)
I use Action as request endpoint. I don't need a lot of features from
it. I doubt that I will be using commands anytime soon instead of
actions. If I wanted to use them as interceptors, I will always be
able to terminate the chain with Action (tenses?)
Command is only better because it does not throw HTTP stuff right in
one's face. Is it really better? Maybe just for testing. From webapp
point of view, Command is as bad as Action. Meaning that HttpServlet
has doGet() and doPost() and therefore forces people to think what
kind of request they are processing and what method is better to use.
Action's only execute() method blurries vision, makes everything a web
service so to speak. Many do not think on what kind of request they
are actually processing and in what other interactions this Action or
a business/UI object represented by this action participates.
After all, until developers move on to GWT or move back to Swing, they
will continue developing against 1995 protocol. It is important to
consider features, quirks and requirements of this protocol despite
popular opinion that protocol-agnostic application is better thing.
http://jakarta.apache.org/commons/chain/changes-report.html
http://jakarta.apache.org/commons/chain/apidocs/index.html
The great benefit of Chain means that having an alternative set of
"request processing" steps becomes much easier and you could develop
something more elegant to support your event style which would
probably mean that the user doesn't need to use either the
DispatchAction or ActionDispatcher at all.
Um, I have to think on this paragraph, I have not got it yet, but
maybe I will get it later, after my head stop aching and I reread it
couple more times :)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
