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