Hi Alexandre Tradeoffs.... Well, I guess we all have to live with them.
Well, back to Shale/Clay/Tiles for some more struggle... :) Hermod -----Original Message----- From: Alexandre Poitras [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 23, 2005 2:54 PM To: Struts Users Mailing List Subject: Re: [shale] Design questions I see. I think most of the time you're right. But in some complex situations a tradeoff *might* be better, instead of having a lot of bloating views, you put the logic in the backing bean. Of course, there are always ways of reorganizing your code like by using JSP tags in JSP views. But I get your point. I am used to do it all the time in the Swing world but as a matter of fact Swing architecture tight the V and the C together. By the way, it has always felt weird to perform it this way, I mean changing the UI components programmatically. Now I understand why so thank! On 11/23/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > 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] > > -- Alexandre Poitras Québec, Canada --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
