Composition is a preferred design instead of inheritance. So, implementing "composition, with inheritance" does not make much sense.
On 11/22/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi > > So how would you implement composition, with inheritance, using Clay > instead of Tiles?. > > Hermod > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Craig > McClanahan > Sent: Tuesday, November 22, 2005 6:15 AM > To: Struts Users Mailing List > Subject: Re: [shale] Design questions > > > 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> <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 > > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > * > > This email with attachments is solely for the use of the individual or > entity to whom it is addressed. Please also be aware that the DnB NOR > Group > cannot accept any payment orders or other legally binding correspondence > with > customers as a part of an email. > > This email message has been virus checked by the virus programs used > in the DnB NOR Group. > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > * > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
