On 7/22/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
Would you mind if I copy-paste relevant pieces into Struts 1 wiki and later in Struts 1 xdocs?
:) I've already done a lot of that in the other direction. :) Depending on what you mean, some material might be suited for the Key Technology Primer. I've tried to avoid duplicating information. What I've brought over, I've tweaked to be s2 specific. For example, they both use the same opening paragraph "Apache Struts 2 is a flexible control layer based on standard technologies like Java Filters, JavaBeans, ResourceBundles, Locales, and XML, as well as various OpenSymphony packages, like OGNL and XWork. The framework helps you create an extensible development environment for your application, based on industry standards and proven design patterns." But, where s2 refers to "Open Symphony", s1 refers to Jakarta Commons. There is a Confluence Wiki available at Apache now. * http://cwiki.apache.org/confluence/homepage.action We are still in the process of moving s2's over, but a question might be whether s1 wants to continue to use moin-moin over the long term.
> For a generic reference to Action class, I'd strongly suggest the term > "action handler". I really don't like calling action a handler. Well yes, it is a request handler, but I would like to reserve "handler" as in "event handler" for dispatch action methods. Also, ASP.NET and JSF uses "event handler" for code-behind class methods, so this way Struts terminology will be in sync.
From a s1/s2 perspective, actions are our events, and Action classes
correlate to how ASP.NET uses code-behinds and JSF uses backing beans. IMHO, It's perfectly appropriate to refer to all of these notions as "handlers". Having written way-too many ASP.NET event handlers over the last year, I don't see a big difference between what we do with a properly-factored action handler and what we do with event handlers. Action handlers are chunkier than event handlers, but the code does the same sorts of things. It's just a matter of how it is factored.
Many pattern libraries like Microsoft's and Martin Fowler's use term "handler" for ActionServlet/RequestProcessor functionality. Again, reusing handler for an action class may confuse some people.
Hmmm, looking at page 340 of PEAA, the term "Page Handler" is used in connection with code a Code Behind file. Having worked extensively with both, I find that both members fill the same niche in a web application. Each framework has a different "spin" on the handler, but in all cases, the key notion is that the handler gives you the opportunity to plugin and execute custom code in response to a request (or other stimuli). On page 337, Fowler talks about using a JSP as "request handler" -- which is an generic description of an Acton Class (script of command) -- a request handler. I would suggest that frameworks like S1, S2, Spring MVC, and others, all utilize a similar strategy that we could characterize as an "action handler" pattern. The front controller matches the incoming request to an action mapping, which includes an action handler. The action handler invokes the core business and data access logic, and suggests a view handler. The controller then dispatches the request to the view handler, which completes the response.
I think that using more generic and neutral word like "worker" suits well both Action and Command. Struts is believed to adhere to service to worker pattern, but it is interesting that there is no "worker" component in that pattern. So let us just call action/command a worker. Sounds pretty good to me. What do you think?
I think worker sounds erudite. If we refer to an Action class/script/command, as the action handler, I think people will understand what we mean without a second thought. I think if we introduce a term like worker, people will wonder if we mean what they think we mean. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
