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?
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
