Hi Forgotten the basics of Tiles, have we?
One of the key features of Tiles is the term definition and template jsp. In the template jsp, you position named generic parts. In the the definition you define what those parts are. This, in my terms, is to compose a page, hence composition. Another key feature of Tiles is that you can define a definition B which extends definition A. In definition B you can override attributes of definitoin A. This, in my terms, is inheritance. SFTH Hermod -----Original Message----- From: Dakota Jack [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 22, 2005 4:05 PM To: Struts Users Mailing List Subject: Re: [shale] Design questions 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~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
