On 1/6/06, Rick Mann <[EMAIL PROTECTED]> wrote: > > Thanks for the response, Craig. It's nice to get an answer from THE > authority :-). Questions below... > > On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote: > > > I'd definitely ignore anything about prereleases of JSF 1.0 ... > > that has > > been out for nearly two years now. A good starting place for > > general JSF > > knowledge and information is <http://jsfcentral.com>. Kito does a > > good job > > of staying on top of the most recent articles and items of > > interest. This, > > by the way, is *exactly* the place to start before looking much at > > Shale > > itself -- Shale *srongly* presumes that you are familiar with JSF, > > and what > > it brings to the table all by itself, because it focuses on adding > > value > > around the edges. Without understanding those edges a little, it's > > harder > > to appreciate the benefits :-). > > Okay, I'll try to find a "hello world" JSF example. That might be > enough for me to build on.
Good. The JSF RI comes with several samples, as does MyFaces. A question comes up: what has happened to Tiles? Is it no longer a > part of Struts? I'm still terribly unfamiliar with the new Struts > website. Tiles itself is definitely still part of the Struts project. Two things are happening to it: * Organizationally, it becomes a subproject of Struts (just like Shale), so that it could be released independently of the rest of the core framework. * Technically, there is a sandbox version of Tiles that has its Struts-Action-Framework dependencies removed, so that it could be used with any MVC framework (and Shale is currently using a snapshot version of this code). Do I bother creating a nice Tiles hierarchy of layouts and tiles? Or > is there some other way to get site L&F re-use? Tiles is still one option for this (indeed, besides the Shale integration, MyFaces's JSF implementation comes with their own integration of the original Struts tiles code.) Another approach is to look for component solutions that do layout management for you -- plus things like the "Clay" plugin to Shale, which lets you accomplish lots of the same sorts of reuse issues, but at a finer grained level than just a page or a tile. The Shale use cases example app has several ways in which Clay can be used like this. If that's not enough technologies to look at :-), there's another interesting approach to reusing layouts called Facelets[1]. Like Clay, Facelets leverages a JSF extensibility point called a "ViewHandler" that lets you be pretty innovative at substituting in alternatives to JSP as the mechanism for authoring the view pages of your application. > Beyond the Shale web site[1], there's not a heck of a lot of stuff > > yet. One > > high level overview is the session I did at ApacheCon (reprised > > from one > > that David Geary and I did at JavaOne)[2] ... but the slides lose a > > little > > in the translation without the corresponding demo program, which is > > not in a > > shape that I'm quite ready to check in yet :-). > > Okay, I'll hold off worrying about Shale for now. Sounds like I can > work it in easily enough when the time comes. We'l be here :-). Here's my big question: do I still think in terms of Struts Actions > handling the business logic of my application (which they rarely do; > they usually glue to the "real" biz code)? Or do I look to putting > all that glue within JSF controllers? For someone familiar with Struts 1.x, I would draw the following analogies: * Where in Struts you have an Action and an ActionForm, with JSF you tend to combine them into a single request scope object. * Where an ActionForm tells you to use Strings for the properties, JSF components deal with conversion for you, so you can use native data types. * It's also possible to bind JSF components directly to POJO model objects if you want ... sorta like what WebWork does too. * Where Struts actions tend to have either a single execute() method for the entire page, or some sort of dispatch mechanism, you tend to bind each submit button in a JSF page to a separate action method in some backing bean (although you can share them if two different buttons should really do the same thing). * Just like an Action in Struts, the action method called by JSF should be considered an adapter to the "real" business logic (although, just like you can do with Struts, it's possible to embed business logic directly in the method :-). * Shale's ViewController adds the notion of application event calbacks to the strictly UI events that JSF supports. Of particular interest is the prerender() callback, which is invoked just before the next page actually renders ... the perfect place to do what you'd put in a "setup action" in a traditionally architected Struts application. As you become more familiar with JSF and Shale, you're likely to end up agreeing with my judgement on the best two features of the combination for an experienced Struts developer contemplating using JSF: * Managed beans extend the Struts concept of magically instantiating ActionForm beans, and makes it general purpose -- they can be created indirectly by virtue of being bound to a component property, or you can evaluate expressions programmatically (with the possible side effects of creating new objects on the fly). Plus, you get basic dependency injection for free ... if your DI needs are relatively simple, you don't need something like Spring -- although you can certainly use that as well if you need it. * Shale dialogs address one of the tougher architectural areas in Struts 1.x ... how to deal with setup actions versus process actions, and how to organize everything. Dialogs lets you divide up your application into states (action state = method execution, view state = page rendering + the following form submit, subdialog state lets you treat dialogs as black box subroutines). Every state returns a logical outcome string, which can be used to drive transitions to other states. And, you can have as many action states as you like between view states. It's pretty easy to architect the overall organization of the application in these terms, and to divide things up into logically separate units of work. Craig Thanks! > > -- > Rick Craig [1] http://facelets.dev.java.net --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
