>Sorry, I didn't do a very good job of explaining. I was trying to describe
>the recursiveness of the XML
>where symbols defined in a outer scope are passed on to nested components but
>nested components can override.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 11/7/05, Gary VanMatre wrote:
> >
> > > On 11/7/05, Gary VanMatre wrote:
> > > >
> > > > >So, are you thinking that "#{shale:managed-bean-name.save}" would be
> > > > >something that would evalutated entirely within a custom shale jsf
> > > > >VariableResolver or would the symbol replac
On 11/7/05, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>
> > On 11/7/05, Gary VanMatre wrote:
> > >
> > > >So, are you thinking that "#{shale:managed-bean-name.save}" would be
> > > >something that would evalutated entirely within a custom shale jsf
> > > >VariableResolver or would the symbol replace
> On 11/7/05, Gary VanMatre wrote:
> >
> > >So, are you thinking that "#{shale:managed-bean-name.save}" would be
> > >something that would evalutated entirely within a custom shale jsf
> > >VariableResolver or would the symbol replacement be done in the clay
> > chain (
> > >i.e. replaceMnemo
On 11/7/05, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>
> >So, are you thinking that "#{shale:managed-bean-name.save}" would be
> >something that would evalutated entirely within a custom shale jsf
> >VariableResolver or would the symbol replacement be done in the clay
> chain (
> >i.e. replaceMnemo
>So, are you thinking that "#{shale:managed-bean-name.save}" would be
>something that would evalutated entirely within a custom shale jsf
>VariableResolver or would the symbol replacement be done in the clay chain (
>i.e. replaceMnemonic) and then passed to the standard VariableResolvers?
A custom
So, are you thinking that "#{shale:managed-bean-name.save}" would be
something that would evalutated entirely within a custom shale jsf
VariableResolver or would the symbol replacement be done in the clay chain (
i.e. replaceMnemonic) and then passed to the standard VariableResolvers?
On 11/7/05
Ryan Wynn wrote:
>I like the direction this is going. My thoughts on this...
>I like the syntax familiar syntax value="#{shale:attribute.class}"/>
>
>However, how about instead of inventing a new syntax
>"#{shale:attribute.class}" we use
>the existing one. For example
>
>
>
>This approach assume
I like the direction this is going. My thoughts on this...
I like the syntax familiar syntax
However, how about instead of inventing a new syntax "#{shale:
attribute.class}" we use the existing one. For example
This approach assumes that clay has defined the existing clay context as a
managed
On 11/5/05, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
>
> On 11/5/05, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>
> > > For the class substitution case that conditionally sets styleClass
> only if
> > > class is actually specified, either the element would need to be smart
> > > about knowing whether
On 11/5/05, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>
> > Note that my original example should probably have been
> >
> > #{shale:managed-bean-name}
> >
> > because we're not actually talking about an attribute here.
> >
> > The issue you raise, of course, is that you're actually trying to replac
> > >
> > > This will become even more important in a JSF 1.2 world, because the EL
> > > expression evaluation machinery has been pulled out into its own spec
> > (and
> > > its own package namespace) that can be used completely independently of
> > the
> > > web tier. Off the top of my hea
On 11/4/05, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>
> > >
> > > > On 11/4/05, Gary VanMatre wrote:
> > > > >
> > > > > > >
> > > > > > > I noticed that Craig commited the
> > > > > > > to
> > > > > > > baseHtml. I think this is good, however I think that now if
> the
> > > symbol
> > > > >
> > >
> >
> > > On 11/4/05, Gary VanMatre wrote:
> > > >
> > > > > >
> > > > > > I noticed that Craig commited the
> > > > > > to
> > > > > > baseHtml. I think this is good, however I think that now if the
> > symbol
> > > >
> > > > > > 'class' is not explicitly specified then the result will be
On 11/4/05, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>
>
> > On 11/4/05, Gary VanMatre wrote:
> > >
> > > > >
> > > > > I noticed that Craig commited the
> > > > > to
> > > > > baseHtml. I think this is good, however I think that now if the
> symbol
> > >
> > > > > 'class' is not explicitly specifi
> On 11/4/05, Gary VanMatre wrote:
> >
> > > >
> > > > I noticed that Craig commited the
> > > > to
> > > > baseHtml. I think this is good, however I think that now if the symbol
> >
> > > > 'class' is not explicitly specified then the result will be > >
> > class="@class"> Is that rig
On 11/4/05, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>
> > >
> > > I noticed that Craig commited the
> > > to
> > > baseHtml. I think this is good, however I think that now if the symbol
>
> > > 'class' is not explicitly specified then the result will be > >
> class="@class"> Is that right, Gar
> >
> > I noticed that Craig commited the
> > to
> > baseHtml. I think this is good, however I think that now if the symbol
> > 'class' is not explicitly specified then the result will be > >
> > class="@class"> Is that right, Gary?
>
>
> Yes, it does do that :-(.
>
> One solution may
lt;[EMAIL PROTECTED]> wrote:
> >
> > Ah, Ryan beat me to the answer. Figures, symbols was his idea anyway.
> >
> >
> >
> >
> >
> >
> >
> > -- Forwarded message ------
> > From: Ryan Wynn <[EMAIL PROTECTED]>
> > To: Struts Users Mailing List
> >
Figures, symbols was his idea anyway.
>
>
>
>
>
>
>
> -- Forwarded message --
> From: Ryan Wynn <[EMAIL PROTECTED]>
> To: Struts Users Mailing List
> Date: Thu, 3 Nov 2005 22:54:38 +
> Subject: Re: [shale][clay] CSS style classes on subst
Ah, Ryan beat me to the answer. Figures, symbols was his idea anyway.
--- Begin Message ---
I believe that currently if the html attribute is not also an attribute on
the underlying component, then the html attribute will be treated as a
symbol.
So, in this case if userNameMessage is actually
On 11/3/05, Ryan Wynn <[EMAIL PROTECTED]> wrote:
>
> Or better yet you could put
> in the attributes of the baseHtml
> component of clay
> and then it would be picked up by all the descendants.
That makes sense to me ... all the JSF standarfd components (and I suspect
lots of third party ones) u
>As part of my JavaOne session on Shale, I demo'd the fact that Clay lets you
>have two different views of the page:
>
>Designer view: http://localhost:8080/myapp/login.html
>
>Developer view: http://localhost:8080/myapp/login.faces
>
>To demonstrate that Clay was actually parsing the HTML template
Or better yet you could put
in the attributes of the baseHtml
component of clay
and then it would be picked up by all the descendants.
On 11/3/05, Ryan Wynn <[EMAIL PROTECTED]> wrote:
>
> I believe that currently if the html attribute is not also an attribute on
> the underlying component, the
I believe that currently if the html attribute is not also an attribute on
the underlying component, then the html attribute will be treated as a
symbol.
So, in this case if userNameMessage is actually a h:message, then
username error message
would produce ... in both the designer and
develope
Beyond the drama of the demo, I would definitely like to see Clay work
the way you suggest. If the CSS styles are picked up from the span
tag, then I can maintain the separation between UI designer and
developer. If the style needs to be specified in the
clay-config.html, then I need to have my d
As part of my JavaOne session on Shale, I demo'd the fact that Clay lets you
have two different views of the page:
Designer view: http://localhost:8080/myapp/login.html
Developer view: http://localhost:8080/myapp/login.faces
To demonstrate that Clay was actually parsing the HTML template, in
log
27 matches
Mail list logo
