Hi Alexandre Ok, that claryfies things a bit. Allthough your example still does not feel right with me. I still think taht anything to do with the view part, such as changing the colour of a text etc. still should be handled in the view. What I would do is to set a condition property in my code, and then in my view I would test for this and act accordingly - See the destinction?
Hermod -----Original Message----- From: Alexandre Poitras [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 23, 2005 1:16 PM To: Struts Users Mailing List Subject: Re: [shale] Design questions Hi hermod, I think you refer to my other post. The author just took the same title. Confusing he? I totally agree with your suggestions. Not a bad idea in my mind but maybe some architectural considerations keep developpers from doing this (tied to jsp instead of url implies it's too tied to the view technology maybe). Just to clarify, maybe I didn't use the right terms. By "managing the UI components", I didn't want to refer to managing their lifecycle like in "managed beans". I guess a better term would have been transforming them, i.e. modifying their properties. For instance, changing the color of a text after an event, something like this. That's the problem with the "french connection" in english, you get used to translate things too litterally :) Anyway, thank for the feedback. Nice to see some discussions on Shale and JSF. On 11/23/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > 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] > > -- Alexandre Poitras Québec, Canada --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
