On 7/6/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > On 7/6/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > On 7/6/05, Adam Hardy <[EMAIL PROTECTED]> wrote: > > > > > > Now there is talk of Struts in the future containing ActionCommands > > > which can be substituted in place of Actions, and strung together in a > > > chain, and presumably can perform View-Controller logic. > > > > > > > If you look at Shale (with its support for both ViewController and > > Dialog -- which, among other things, lets you intersperse action > > states and view states to your heart's desire), you'll find that the > > future is now :-) > > > > http://struts.apache.org/shale/ > > > > Craig > > Moved to the new thread. > > From http://struts.apache.org/shale/features.html#view > > "Each backing bean that implements ViewController will support a > boolean property postback, which will be set to true if this view is > the one that is processing a form submit previously rendered by the > same page, or false if this view was newly navigated to." > > * How is this different from ASP.NET?
The ViewController part of Shale is indeed very similar to the way that ASP.NET implements the View Helper design pattern. From a usability perspective, especially for developers not as well versed in object oriented programming concepts, Microsoft got this right -- which was one of the motivations for JSF making the same style easy to accomplish in Java. When you are focused on a particular page, it is very convenient to think of everything that happens related to that page being a response to a particular event -- with all the events for a particular page conveniently represented as public methods on a single backing bean (code behind file in ASP.NET terminology). The prerender() method, as well, performs exactly the same function as the Controller interface in Tiles -- it provides a perfect place to acquire resources that are *only* required if you are the page that is going to be rendered. Struts 1.x supports exactly the same paradigm; it's just not as pretty -- a setup action that preceeds the rendered view action. ViewController doesn't require you to do that extra step (or try to deal with the problematic action chaining issues that plague Struts 1.x, when you submit to the processing action for the previously rendered form, then need to navigate to the setup action for the form about to be rendered). And, if you go on and also use the Dialog feature of Shale, you can have as many different action states (each represented by a method call, expressed as a method binding expression so the business logic classes need have no knowledge of JSF or Shale) as you want in between your views. So, if you like the way a chain of responsibility pattern (like Commons Chain) lets you decompose business processes into fine grained reusable chunks, you can do that too. > * Does not this make Shale page-based instead of front-controller > based? MS recognized lack of front controller support in ASP.NET 1.0 > and will provide it to the second version. No, it makes the *ViewController* part of Shale page based, as it should be :-). The rest of Shale (in particular the controlling filter where you can plug in anything that is supposed to happen once per request, like an authentication filter) is still a front controller. You can impose whatever overall processing you want on each request, simply by composing the Commons Chain command that the filter applies to each request. Besides the biggest difference (from Struts) of being JSF based, this architectural principle is the second major difference in Shale, and it results from the most important lesson I've learned by watching how people use (and misuse) Struts -- the controller framework should consist of fine grained components that can be combined or customized as necessary to meet particular application requirements. If a particular application needs, say, authentication filtering, then plug it in. If that app also needs logging, or tracing, plug that in too (no having to worry about subclassing RequestProcessor and then running into Java's single inheritance limitation. At the same time, it is up to the application architect if they want to build up the specialized processing needed for an individual request by composing with reusable logic blocks. You can do this easily with Shale, either by calling common reusable code chunks from methods like prerender() and destroy() when using ViewController, or by composing the action states in between your views when using Dialog. The front controller managing the entire application need not be involved in figuring out what specialized resources the particular processing path for a given request will need -- although you could even do that in the application level filter, if you really wanted to. Your choice. What's interesting about the current discussion is that things like DispatchAction and LookupAction, as well as the idea of action commands, are all an attempt to retrofit exactly the same concept of fine grained management of individual interactions onto the monolithic controller of Struts 1.x. As some have observed, the two approaches don't necessarily fit together very well -- although you can certainly do it with some bending and twisting. But the architectural model of an application that Shale presents to the developer, once you learn it, is *much* simpler to program to, as well as being easier to configure. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
