On 11/21/05, Alexandre Poitras <[EMAIL PROTECTED]> wrote: > > Hi! > > First of all, congratz on the good job. Shale looks very promising. We are > currently implementing JSF in my organization. I already knew about Shale > but I hadn't checked its progress in a while and I must say I am impressed > so far. Actually, I stumbled upon the project while I was looking for a > way > to build in a quick way new UI components. The idea of creating 3 > different > classes each time to be able to aggregate some already existing UI > components didn't sound particulary attractive. And that's how I found the > "goodies" of Shale.
Welcome! Anyway, to make it short, I am experimenting Clay's feature right now but I > am a little bit confused. There seems to be a bit of overlap between Tiles > and Clay features? Am I correct? And if it's true, is it a better choice > to > keep using Tiles as my layout manager or should I do it the Tapestry's way > and treat everything as a UI component with the help of Clay? Clay is ... um, err ... pretty malleable :-). And yes, from the point of view of layout templating, there is definitely overlap. Tiles support has been a highly requested capability for JSF based applications, primarily because existing Struts developers are comfortable with it, and being able to reuse that capability meant a little bit less of an initial learning curve was necessary. My personal feeling is that Clay (or a similar project at java.net <http://java.net> called facelets) will become more popular for people coming to JSF without a large Struts legacy. The approach is more flexible and fine grained, and it wouldn't surprise me if we can make it perform better as well since it omits the need to use the container's RequestDispatcher.include() functionality. Another thought that keeps rambling through my head is a question concerning > the backing beans design. I have red on many blogs entries that one of the > greatest strength of JSF is the fact that the backing beans don't have to > implements any interfaces. But if you want to take advantage of Shake > "page > level" services infrastructure (the view package), your beans have to > implement the ViewController interface. Don't get me wrong, I think those > services are great tools but I was wondering if all the beans should be > "ViewController" instances or just when it is absolutly necessary? My personal habit is to use the interfaces all the time ... then I can focus my attention on the event driven parts of the design, and never run into situations where I define an init() method later, but it never gets called ... because I forgot to add "implements ViewController" up at the top of the class. Even better, if you're going to commit to doing this anyway, is to "extends AbstractViewController" instead of "implements ViewController". Not only does this give you a bit of protection if ViewController ever changes, it also gives you a bunch of other nice convenience methods that makes things like the programmatic evaluation of value binding expressions much easier. One of the reasons people tout the "no required interfaces" possibility in JSF as an advantage is that it makes backing beans much easier to build unit tests for. However, Shale's approach is to protect this testability advantage, while still giving you the usability advantages of the extra events. It even includes a test framework to help you build unit tests for your view controllers very easily. Finally, > another concern I have with this approach is that it's kind of suggesting > you to write one bean for each page of the application (using a 1:1 > mapping). From all the research I have done in the JSF area, I have not > been > able to find a consensus about wich approach to use when designing backing > bean. Actually, it's hard to find some documentation on backing beans > design > but I think it's one of the challenges Struts developpers (as I am) face > when moving to JSF. I would like to hear from the Shale users or/and > developpers their opinion on the subject? Any advantage or downside? Ironically, my preferred design for backing beans is going to be something more familiar to WebWorks users than it is to Struts users, because it's closer to the way WebWorks already works :-). In Struts terms, think of the backing bean as a combination of an ActionForm and an Action, but with some additional flexibility: * Like an ActionForm, the bean would have a getter and setter for each form field. Unlike an ActionForm, the property types can be the appropriate native type (int, Date, or whatever you need) because JSF handles type conversions instead of making you do it. You would typically use a value binding expression on the component that binds the "value" property of the component to this property on the backing bean ... something like: <h:inputText id="maxItems" value="#{mybackingbean.maxItems}" .../> where the backing bean has the following property: private int maxItems = 0; public int getMaxItems() { return this.maxItems; } public void setMaxItems(int maxItems) { this.maxItems = maxItems; } * Like an Action, you define an event handler for when the form is submitted. However, you're not restricted to a single such event handler on an existing form. It's quite common to have multiple submit buttons that do different things, but very convenient to bind them to different execute methods in the same bean (so they all have access to the form field properties). This is sort of like using DispatchAction in Struts, but the dispatching logic is implicit in how you do your bindings, instead of explicit in the base class. Bind a submit button to an action method like this: <h:commandButton id="save" action="#{mybackingbean.save}" .../> where the save() method is defined like this: public String save() { ... } in the same backing bean that the form fields are found. Now, you have direct access to the form field values, because they will have been converted, validated, and populated before the save() method is called. * If your UI design has multiple buttons that should invoke the same action (such as a Save button at the top and the bottom of a long list), feel free to bind them to the same action method. On the other hand, if you have "Save" and "Cancel" buttons that should do something different, simply bind them to different action methods. * Backing beans should generally be placed in request scope, so a new instance will get created on every request. Among other things, that means you do not have to worry about thread safety the way you do in an Action. Instance variables are fine. * Most of the above principles are pure JSF ... for Shale you would typically either implement ViewController or extend AbstractViewController on these backing bean classes, to gain the benefits of the extra event callbacks and the utility functions. Thank for any hints! Really appreciated! > > *Sorry for any mistakes I made but english isn't my native language. You don't need to apologize ... your English is fine. -- > Alexandre Poitras > Québec, Canada > > Craig
