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
