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
>
