Hi Alexandre Mostly I aboslutly agree with you, but there is one thing that I am not comfortable with: "..and so managing some of your UI components programmaticaly is impossible."
What you are promoting here, is mixing view and controller, but since Craig is promoting the use of one backing bean pr. view (page?), this may or may not be viable. Allthough I do not think that the thought behind it is what you want. One of the things that I do not like is that we might be getting into a situation here where we have some of the "logic" for creating a page in xml definition files, and some of it in code (as you want to do). This may lead us into a situation where we may kind of loose sight of as to where things get defined. I think that it is a "cleaner" aproach to have things in one place, and not scatter it around. Just my 2c worth. I recently posted a suggestion that the backing beans (ViewControllers) be bound to .jsp pages, and not to URI's when using Tiles. As far as I can see I have not got a clear answer to this. This goes exactly to the problem at hand here: Tiles. Since the individual tiles may be reused in many pages, not having the ability to do prerender on the tiles, but only on the page kind of defeats the purpose of Tiles. It means you are going to have to duplicate code in variuos backing beans. It would be really nice to have it as Winny the poo: Yes, please. I.e both on pages and on .jsps (tiles). I guess one way of solving it would be to implement something portal like. Hermod -----Original Message----- From: Alexandre Poitras [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 23, 2005 5:17 AM To: Struts Users Mailing List Subject: Re: [shale] Design questions I kind of agree with you Gary. I just love Tiles powerful features and I would like to use it in my JSF application (but I would take a deep look at Tapestry way of doing it to see if it is truly necessary). Anyway, I started to have concerns after watching the JavaOne 2005 presentation "Extreme Reuse in JavaServer Faces, TS-7853" (wich was very interesting by the way). There seems to be a lot of non-obvious concerns when using non-JSF aware technologies for the layout of a JSF view. I know that Shale provides an integration ViewHandler for Tiles wich allow him to resolve ".pages" urls and eliminates the need for stupid jsp wrappers but I think it resolves only part of the problem. Here's a small summary of the main issues for those who don't have time to watch the presentation. First, even if it's not such a huge concern but still have to be taken in account when designing the application, navigation rules are relative to the top viewid and not the tile itself. It can be a bit confusing but I guess you can find your way around it. Second, you can't use some more "advanced" Tiles functionnalities like importAttributes (see the presentation). Again you are sticking to a basic usage, I still think Tiles can be a valid solution. But the main problem come from the fact that Tiles is for the moment not a solution specific to JSF technology and provides no adapters for this framework. Therefore, a tile is sadly not a JSF UI component. It's mean that JSF Beans can't see your application tiles. You can say goodbye to the use of the binding attribute and so managing some of your UI components programmaticaly is impossible. This is a huge limitation in my opinion. Maybe Shale already solves those issues but from what I have read on the Javadoc page, it doesn't seem to. I think people should be aware of those issues to make a discern choice. Just my two cents. I'll be glad to hear any nice solutions to those problems if someone has any ideas. *By the way, the Rolodex use case seems to be broken for the moment except for the jsp example. Both of the Html views and the Xml view output <span class="@class"> around every element. For example, the first line is shown like this <span ...><html></span> (IE is able to render the page but not Firefox of course :)). On 11/22/05, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > > > Hi > > > > So how would you implement composition, with inheritance, using Clay > instead of > > Tiles?. > I'm a big fan of Tiles and think that Clay and Tiles have their own > niches. I see tiles as a tool for assembling page fragments in a reusable > way. Clay is at a more granular level. It's focus is on assembling a page of > reusable widgets. > > > There are many ways to use Clay but I'll give the following example of > inheritance and composition. > > > <component jsfid="baseInputText" extends="inputText"> > <attributes> > <!-- Convention mapping "class" attribute to "styleClass" property --> > <set name="styleClass" value="@class"/> > > > </attributes> > <symbols> > <set name="class" value="generic" /> > </symbols> > </component> > > > > > <component jsfid="panel" extends="panelGrid"> > > > <element jsfid="baseInputText" renderid="0" > > <attributes> > <set name="value" value="[EMAIL PROTECTED]"/> > </attributes> > <symbols> > <set name="class" value="blue" /> > </symbols> > </element> > > > <element jsfid="baseInputText" renderid="1" > > <attributes> > <set name="value" value="[EMAIL PROTECTED]"/> > </attributes> > <symbols> > <set name="class" value="green" /> > </symbols> > </element> > </component> > > > Elements form composition but also add inheritance similar to a java inner > class. The new symbol replacement is sort of a tiles like feature where you > can customize by overriding a symbol value. > PS: I'm on vacation this week and have limited Internet access. > > > > > Hermod > > > > Gary > -- Alexandre Poitras Québec, Canada * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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]
