I have no idea sincerely. It is a very good point indeed. I was just throwing this idea because autogenerated content sometimes is a pain in the a** and writting a class to output content doesn't seem right to me.
On 12/6/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > On 12/6/05, Alexandre Poitras <[EMAIL PROTECTED]> wrote: > > > > I found out a menu component was already available in Tomahawk. It would > > be > > great if it was possible using Clay to build a new Renderer in case the > > html > > generated is not alright for any reason (here for example we have to > > respect > > XHTML strict so it's always a concern) but I guess it's not possible > > because > > a renderer is not a UI component (saved in the view tree). > > > > The renderer is not saved in the component tree, but the component is ... > and it is the rendererType property of the component that determines which > renderer will actually be used. > > It might be feasible to write a sort of general purpose renderer that > mapped > a particular component type (or component family) to a particular Clay > template somehow. That would take care of the output side of things, but > how would you propose to handle the decoding of an input component? > > Craig > > > On 12/5/05, Alexandre Poitras <[EMAIL PROTECTED]> wrote: > > > > > > I see. I guess you're right but again I have a problem I have to ship > it > > > as a custom component because this kind of menu is quite common. So I > > guess > > > what you suggest is to use a helper class and ship it with the > component > > > itself. > > > > > > Thank for your advices. Sorry if I ask many questions but I am trying > to > > > get the grasp on Shale-Clay and establishing some personal "best > > practices". > > > There are so many possibilities with this component. > > > > > > On 12/5/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > > > > > > On 12/5/05, Alexandre Poitras <[EMAIL PROTECTED]> wrote: > > > > > > > > > > I know about rendered but it's not about changing the visibility > but > > > > > changing the style class. In fact I want to add 'active' to the > > value > > > > of a > > > > > menu element style class, depending of wich one is activated. > > > > > > > > > > I think I could do it with rendered but my concern is to end up > with > > a > > > > lot > > > > > of non desired components in memory, ie 2 for each elements of my > > menu > > > > > > > > > (active and normal). > > > > > > > > > > What do you think? > > > > > > > > > > > > To change the style class dynamically, I'd use a value binding on > the > > > > styleClass property, pointing at a getter method that can calculate > > the > > > > appropriate value based on the current state of the world. > > > > > > > > Craig > > > > > > > > > > > > On 12/5/05, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > You will probably need to look at using the rendered attribute > of > > > > the > > > > > > component. This is the JSF way of changing the visibility > > > > dynamically. > > > > > > > > > > > > rendered="#{mybean.isSomethingVisible}" > > > > > > <set name="rendered" value="#{ mybean.isSomethingVisible}"/> > > > > > > > > > > > > Gary > > > > > > > > > > > > -------------- Original message -------------- > > > > > > > > > > > > > Guess what? > > > > > > > > > > > > > > I need an "if component" now (to change some visual > attributes). > > > > Of > > > > > > course, > > > > > > > I could code the component but I really prefer to do it in a > > > > > declarative > > > > > > way > > > > > > > à la JSTL. Tags file weren't invented for nothing afterall so > I > > > > guess > > > > > > Shale > > > > > > > should follow this direction too. I'll probably try to > implement > > > > it > > > > > > myself > > > > > > > if I have enough time tonight. > > > > > > > > > > > > > > On 12/4/05, Gary VanMatre wrote: > > > > > > > > > > > > > > > > > Look great to me. I am just wondering how sessionScopeVar > is > > > > > > working? Is > > > > > > > > it > > > > > > > > > like the "var" argument in JSTL? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yep, it's like the var. Maybe it would be better to name it > > > > "var" > > > > > and > > > > > > > > provide a "scope" attribute for request or session. I went > > with > > > > > > session to > > > > > > > > avoid the same questions about the updatable dataTables. > > > > > > > > > > > > > > > > The difference is that the target "sessionScopeVar" object > > will > > > > be a > > > > > > map > > > > > > > > and the keys are generated to match the generated el for the > > > > > > substitution of > > > > > > > > the @managed-bean-name symbol. This allows the default > > decoding > > > > to > > > > > > work > > > > > > > > without having the responsibility of the dataTable > component. > > > > > > > > > > > > > > > > > By the way, what I like about this approach is that we > don't > > > > have > > > > > to > > > > > > > > hide > > > > > > > > > everything behind JSF components. I was wondering why I > > would > > > > need > > > > > > to > > > > > > > > write > > > > > > > > > a list component while in fact a list or a table is just a > > > > > specific > > > > > > use > > > > > > > > of a > > > > > > > > > forEach component. It will allow developpers to develop > > simple > > > > > > > > components > > > > > > > > > quickly just by reusing basic building blocks :) That was > a > > > > big > > > > > > weakness > > > > > > > > of > > > > > > > > > JSF in my mind to always have to write code to develop new > > > > > > components. > > > > > > > > So > > > > > > > > > great job! I love this feature. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cool. These "amalgam" functions are a mix of runtime Clay > > > > binding > > > > > > > > events. Kind of a dynamic flavor of the XML and HTML > > > > > > configs/templates. > > > > > > > > > > > > > > > > > > > > > > > > > By the way, maybe you should consider in your design that > > some > > > > > more > > > > > > > > logic > > > > > > > > > components might be add in the future (I don't know how > many > > > > > > Tapestry > > > > > > > > has > > > > > > > > > but it should give us a good estimation). So I guess > putting > > > > that > > > > > in > > > > > > > > > ClayAmalgam is fine for the moment but it can become > bloated > > > > over > > > > > > time. > > > > > > > > Just > > > > > > > > > my two cents. > > > > > > > > > > > > > > > > > > > > > > > > > I agree about the bloating of the ClayAmalgam class. Even if > > it > > > > was > > > > > > > > organized similar to the JSTL libraries (c, fmt, x,..) it > > would > > > > be > > > > > > > > bloated. I guess we could break each function out into a > > > > separate > > > > > > class. > > > > > > > > Then we might have ClayAmalgamImport, ClayAmalgamOut, > > > > > > > > ClayAmalgamForEach. Or, make "ClayAmalgam" the managed bean > > name > > > > of > > > > > a > > > > > > map > > > > > > > > in application scope that contains Out, Import and ForEach > > > > entries. > > > > > > Maybe > > > > > > > > it will be more clear when we have a few more. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Alexandre Poitras > > > > > > > > > Québec, Canada > > > > > > > > > > > > > > > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Alexandre Poitras > > > > > > > Québec, Canada > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Alexandre Poitras > > > > > Québec, Canada > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Alexandre Poitras > > > Québec, Canada > > > > > > > > > > -- > > Alexandre Poitras > > Québec, Canada > > > > > > -- Alexandre Poitras Québec, Canada