Intro ----- Struts sucks (c) Jason Carreira. Struts implements Front Controller pattern. ==> Front Controller pattern sucks ==> ASP.NET does not suck because it uses Page Controller pattern ==> J2EE must have its own non-sucky Page Controller framework ==> JSF has been born ==> JSF does not suck!
Meanwhile, Microsoft adds Front Controller support into ASP.NET 2.0 because many ASP.NET developers think that Page Controller sucks ==> JSF sucks because it is a Page Controller framework too ==> Front Controller and Page controller patterns suck, JSF and ASP.NET suck too ==> Everything sucks and we all will die. Umm, my conclusions must be flawed, because everything cannot be *that* bad. Let's see, it is incorrect to conclude that a pattern sucks judging by one implementation. It is improper to conclude that because one pattern sucks, another one does not. Also, as I was told, JSF is not strictly a Page Controller framework. Anything else? Here, here, found one (see below). Struts is not a Front Controller framework ------------------------------------------ After three Margaritas that I had last night, I see it all clearly now. Either Sun's definition of Front Controller is flawed or Front Controller is not what I though it was. Sun defines duties of Controller like this[1]: "Typically, a controller coordinates with a dispatcher component. Dispatchers are responsible for view management and navigation. Thus, a dispatcher chooses the next view for the user and vectors control to the resource." So, according to Sun, a dispatcher chooses next view and "vectors control" to the resource. In Struts terms, dispatcher is an Action. Works for Struts, eh? My understanding of Front Controller was that controller *selects* a command, or a view or a helper. The idea that the controller must actually *perform a selection* resonates with Microsoft's definion of Front Controller[2]: "Front Controller solves the decentralization problem present in Page Controller by channeling all requests through a single controller. The controller itself is usually implemented in two parts: a handler and a hierarchy of commands. The handler has two responsibilities: * Retrieve parameters. The handler receives the HTTP Post or Get request from the Web server and retrieves relevant parameters from the request. * Select commands. The handler uses the parameters from the request first to choose the correct command and then to transfers control to the command for processing." See? The handler, which is part of controller, *chooses* the correct command. This definition seems more appropriate for me. Does this happen in Struts? No way. In a Struts applicaiton the request already contains action mapping name, that is, a client sends request to a specific action! Controller selects nothing, it just performs some housekeeping tasks like initializing actions and forms. This is it. Therefore, Struts is based on interceptor pattern, nothing more, nothing less. COR, introduced in Struts 1.3, is a logical development of a rather monolythic implementation of this pattern in prior versions. I am not an authority on patterns, but it seems to me that Sun "patched" its definition of Front Controller to match Struts architecture. Whatever. Before- and After- actions. Where did this come from? ----------------------------------------------------- First off, I prefer to call them Before and After instead of Pre and Post to not mix Post-action with POST request method. Now, how does Before-After pattern fits Front Controller pattern? Well, they are orthogonal. Anyone who is saying that Before-After pattern is an inherent part of Front Controller is lying his ass off. To me, the Before-After pattern is the very approach that makes people shout "Struts is abomination!". Think of it. According to Before-After pattern one JSP page needs two actions: one to display it for the first time and another to collect the input. What happens if input is invalid? The page is redisplayed, now from the After-action. So, two actions perform the same duty: [re]display a page. Don't even get me started on two different URLs for the same page. What if input is correct? then After-action usually displays success page. Now one action handles two pages. This is M:M relationship, which can be called differently: a nightmare. There is absolutely nothing intuitive in this pattern. Yuck. (I hope WebWork does not use this, eh, pattern). Action as web resource: bring the sanity back --------------------------------------------- In Struts an action is what a user navigates to from the browser (GET, load resource). Also, an action is the place where event/command is sent (POST, manipulate resource). With Struts, browser works with actions. On the other hand, browser generally works with *resources* ==> an action represents a resource. Resource is an object that can be displayed or manipulated ==> one action as a proxy for a particular resource, should render resource's view (forward to JSP page) as well as accept commands to manipulate the resource. One resource -> one action -> one or multiple views. Simple. DispatchAction: event-processing model -------------------------------------- DispatchAction and its flawors allow to define events and to link events to handler methods. Now you have it: * DispatchAction defines a web resource and handles GETs and POSTs * On GET (load resource) DispatchAction displays an appropriate view * On POST (called postback event in some *other* frameworks) DispatchAction invokes appropriate handler and then either: - redirects to another action (another resource) - forwards to a view (renders this resource's view) - redirects to itself (thus rendering a view in a separate request) The above solution keeps Front Controller pattern (interceptor pattern, whatever) intact. It provides clean 1:1 relationship between action's URL, action and resource. It provides clean event model like in Page Controller frameworks. Redirection? Session scope? Yes, I do like them. But you don't have to use them if you don't want to. Use forwarding. From the conceptual point of view it is still better than Before-After antipattern. Objections? [1] Core J2EE Patterns - Front Controller, http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html [2] MSDN, Front Controller Pattern http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpatterns/html/DesFrontController.asp [3] Service To Worker pattern, http://livedocs.macromedia.com/jrun/4/Programmers_Guide/designpatterns6.htm#1114513 Michael Jouravlev. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
