Re: [shale][clay] CSS style classes on substituted elements
>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. > > > > > > > > > > > > > > > > > > > > > > > > > >In this example, street1 should have a 'styleClass=default' and >street2 will have a 'styleClass=override'. > >Unless the "class" symbol was saved multiple times in the request with a >unique name, the last value would take precedence. Hey Craig, what about creating ValueBinding and MethodBinding decorators and hang the symbol table off the decorated binding object? A similar approach to how literal string action's are handled. Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale][clay] CSS style classes on substituted elements
> 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 replacement be done in the clay
> > > > chain (
> > > > >i.e. replaceMnemonic) and then passed to the standard
> > VariableResolvers?
> > > >
> > > > A custom VariableResolver is what I was thinking. The variable
> > resolver
> > > > would use the symbol table cached in thread scope to resolve the
> > symbols.
> > > >
> > > > I'm hoping that Craig will be able to help out on this one:-)
> > >
> > >
> > > Ryan's idea is definitely a good one. And it raises a quick question ...
> > is
> > > the ClayContext already stored as a request attribute under name
> > > "clayContext"? If so, we might not need much help at all.
> > >
> >
> > Nope, it's not but wouldn't hard to push it there. Something I'm not
> > certain about is when a variable resolver would be invoked. Is it when the
> > binding object is created or when the binding is invoked? If it's when the
> > binding is created, I think that request scope would work out. Otherwise, I
> > believe there will be a scoping issue.
>
>
> It's invoked when you evaluate the expression, not when the binding is
> created, so things should work fine.
>
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.
In this example, street1 should have a 'styleClass=default' and
street2 will have a 'styleClass=override'.
Unless the "class" symbol was saved multiple times in the request with a unique
name, the last value would take precedence.
> When the AssignChildrenCommand is invoked, it builds the current symbol
> > table. This is "scoped" for the creation of the child. The component symbol
> > metadata (ComponentBean.getSymbols()) overrides anything in an outer
> > scope. If the child is a nested clay component, the managed bean name will
> > also override the current value in the symbol table. Since the symbol
> > replacement happens before the binding expression is established, the
> > resulting value is kept by the component.
>
>
> Sounds good.
>
> > Craig
> > >
> >
> > Gary
> >
>
> Craig
>
Gary
Re: [shale][clay] CSS style classes on substituted elements
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 replacement be done in the clay
> > > chain (
> > > >i.e. replaceMnemonic) and then passed to the standard
> VariableResolvers?
> > >
> > > A custom VariableResolver is what I was thinking. The variable
> resolver
> > > would use the symbol table cached in thread scope to resolve the
> symbols.
> > >
> > > I'm hoping that Craig will be able to help out on this one:-)
> >
> >
> > Ryan's idea is definitely a good one. And it raises a quick question ...
> is
> > the ClayContext already stored as a request attribute under name
> > "clayContext"? If so, we might not need much help at all.
> >
>
> Nope, it's not but wouldn't hard to push it there. Something I'm not
> certain about is when a variable resolver would be invoked. Is it when the
> binding object is created or when the binding is invoked? If it's when the
> binding is created, I think that request scope would work out. Otherwise, I
> believe there will be a scoping issue.
It's invoked when you evaluate the expression, not when the binding is
created, so things should work fine.
When the AssignChildrenCommand is invoked, it builds the current symbol
> table. This is "scoped" for the creation of the child. The component symbol
> metadata (ComponentBean.getSymbols()) overrides anything in an outer
> scope. If the child is a nested clay component, the managed bean name will
> also override the current value in the symbol table. Since the symbol
> replacement happens before the binding expression is established, the
> resulting value is kept by the component.
Sounds good.
> Craig
> >
>
> Gary
>
Craig
Re: [shale][clay] CSS style classes on substituted elements
> 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. replaceMnemonic) and then passed to the standard VariableResolvers?
> >
> > A custom VariableResolver is what I was thinking. The variable resolver
> > would use the symbol table cached in thread scope to resolve the symbols.
> >
> > I'm hoping that Craig will be able to help out on this one:-)
>
>
> Ryan's idea is definitely a good one. And it raises a quick question ... is
> the ClayContext already stored as a request attribute under name
> "clayContext"? If so, we might not need much help at all.
>
Nope, it's not but wouldn't hard to push it there. Something I'm not certain
about is when a variable resolver would be invoked. Is it when the binding
object is created or when the binding is invoked? If it's when the binding is
created, I think that request scope would work out. Otherwise, I believe there
will be a scoping issue.
When the AssignChildrenCommand is invoked, it builds the current symbol table.
This is "scoped" for the creation of the child. The component symbol metadata
(ComponentBean.getSymbols()) overrides anything in an outer scope. If the
child is a nested clay component, the managed bean name will also override the
current value in the symbol table. Since the symbol replacement happens before
the binding expression is established, the resulting value is kept by the
component.
> Craig
>
Gary
Re: [shale][clay] CSS style classes on substituted elements
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. replaceMnemonic) and then passed to the standard VariableResolvers?
>
> A custom VariableResolver is what I was thinking. The variable resolver
> would use the symbol table cached in thread scope to resolve the symbols.
>
> I'm hoping that Craig will be able to help out on this one:-)
Ryan's idea is definitely a good one. And it raises a quick question ... is
the ClayContext already stored as a request attribute under name
"clayContext"? If so, we might not need much help at all.
Craig
Re: [shale][clay] CSS style classes on substituted elements
>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 VariableResolver is what I was thinking. The variable resolver would
use the symbol table cached in thread scope to resolve the symbols.
I'm hoping that Craig will be able to help out on this one:-)
Gary
--- Begin Message ---
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, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>
> 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 assumes that clay has defined the existing clay context as
> a
> >managed-bean in request scope and pushed it's value appropriately during
> the
> >evaluation. So styleClass is evaluted just like any other VB.
> >This also takes care of the set-if case, because if the symbol is not
> >defined in the symbols map then the result will be null, and you would
> not
> >get .. but rather the correct response of
> >... in the case that the class symbol is not set.
> >
> >So just to explain further.. in clays faces-config.xml
> >
> > clayContext
> > org.apache.shale.clay.component.chain.ClayContext
> >
> > request
> >
> >
> >That way there is not need to invent a new el evaluation and no need to
> add
> >
>
> Ryan, you have a good point. This could be made simpler in terms of
> implementation. But, it sounds as if the namespace qualifier is more inline
> with the future of EL. I wouldn't be against the simpler syntax but the
> "#{shale:managed-bean-name.save}" looks pretty slick.
>
> I don't think the managed bean name would work with this syntax
> "#{symbols['managed-bean-name'].saveAction} since it's a partial
> replacement.
>
> I guess that something like this might work, '#{managedBeanName['save']}',
> where the managedBeanName is a custom map implementation and it returns
> another expression, #{mybean.save}.
>
>
>
> Gary
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--- End Message ---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale][clay] CSS style classes on substituted elements
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, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>
> 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 assumes that clay has defined the existing clay context as
> a
> >managed-bean in request scope and pushed it's value appropriately during
> the
> >evaluation. So styleClass is evaluted just like any other VB.
> >This also takes care of the set-if case, because if the symbol is not
> >defined in the symbols map then the result will be null, and you would
> not
> >get .. but rather the correct response of
> >... in the case that the class symbol is not set.
> >
> >So just to explain further.. in clays faces-config.xml
> >
> > clayContext
> > org.apache.shale.clay.component.chain.ClayContext
> >
> > request
> >
> >
> >That way there is not need to invent a new el evaluation and no need to
> add
> >
>
> Ryan, you have a good point. This could be made simpler in terms of
> implementation. But, it sounds as if the namespace qualifier is more inline
> with the future of EL. I wouldn't be against the simpler syntax but the
> "#{shale:managed-bean-name.save}" looks pretty slick.
>
> I don't think the managed bean name would work with this syntax
> "#{symbols['managed-bean-name'].saveAction} since it's a partial
> replacement.
>
> I guess that something like this might work, '#{managedBeanName['save']}',
> where the managedBeanName is a custom map implementation and it returns
> another expression, #{mybean.save}.
>
>
>
> Gary
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: [shale][clay] CSS style classes on substituted elements
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 assumes that clay has defined the existing clay context as a
>managed-bean in request scope and pushed it's value appropriately during the
>evaluation. So styleClass is evaluted just like any other VB.
>This also takes care of the set-if case, because if the symbol is not
>defined in the symbols map then the result will be null, and you would not
>get .. but rather the correct response of
>... in the case that the class symbol is not set.
>
>So just to explain further.. in clays faces-config.xml
>
> clayContext
> org.apache.shale.clay.component.chain.ClayContext
>
> request
>
>
>That way there is not need to invent a new el evaluation and no need to add
>
Ryan, you have a good point. This could be made simpler in terms of
implementation. But, it sounds as if the namespace qualifier is more inline
with the future of EL. I wouldn't be against the simpler syntax but the
"#{shale:managed-bean-name.save}" looks pretty slick.
I don't think the managed bean name would work with this syntax
"#{symbols['managed-bean-name'].saveAction} since it's a partial replacement.
I guess that something like this might work, '#{managedBeanName['save']}',
where the managedBeanName is a custom map implementation and it returns another
expression, #{mybean.save}.
Gary
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale][clay] CSS style classes on substituted elements
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-bean in request scope and pushed it's value appropriately during the
evaluation. So styleClass is evaluted just like any other VB.
This also takes care of the set-if case, because if the symbol is not
defined in the symbols map then the result will be null, and you would not
get .. but rather the correct response of
... in the case that the class symbol is not set.
So just to explain further.. in clays faces-config.xml
clayContext
org.apache.shale.clay.component.chain.ClayContext
request
That way there is not need to invent a new el evaluation and no need to add
On 11/5/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
>
> 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 there was really a value there, or we could do
> a
> > "set
> > > > if" operation that only performed the set if the expression
> evaluated
> > to
> > > > something other than null or empty string:
> > > >
> > > >
> > > >
> > > > where the expression would evaluate the value of the "class"
> > attribute, if
> > > > it exists, and perform the set only if a non-null non-empty-string
> > value was
> > > > returned by evaluating the expression.
> > > >
> > >
> > > That's a interesting idea. Or, we might be able to use a new
> > "bindingType" in the "set" node. But, a "set-if" might be more
> descriptive.
> > >
> >
> >
> > Does that mean there are scenarios where one wouldn't want the
> > behavior in Craig's first suggestions (a "smart" if)? If there aren't,
> > IMO, it makes sense to do that since this is one of the cases where
> > less is more and not having to remember to differentiate between
> > and is a good thing while authoring.
>
>
> Good point. I cannot think of any use cases for the non-conditional
> setting
> off the top of my head, but a "conditional pass-through only if the origin
> is not null" seems like a very common case.
>
> Craig
>
>
> -Rahul
> >
> >
> > > > Craig
> > > >
> > >
> > > Gary
> > >
> > >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
Re: [shale][clay] CSS style classes on substituted elements
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 there was really a value there, or we could do a > "set > > > if" operation that only performed the set if the expression evaluated > to > > > something other than null or empty string: > > > > > > > > > > > > where the expression would evaluate the value of the "class" > attribute, if > > > it exists, and perform the set only if a non-null non-empty-string > value was > > > returned by evaluating the expression. > > > > > > > That's a interesting idea. Or, we might be able to use a new > "bindingType" in the "set" node. But, a "set-if" might be more descriptive. > > > > > Does that mean there are scenarios where one wouldn't want the > behavior in Craig's first suggestions (a "smart" if)? If there aren't, > IMO, it makes sense to do that since this is one of the cases where > less is more and not having to remember to differentiate between > and is a good thing while authoring. Good point. I cannot think of any use cases for the non-conditional setting off the top of my head, but a "conditional pass-through only if the origin is not null" seems like a very common case. Craig -Rahul > > > > > Craig > > > > > > > Gary > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [shale][clay] CSS style classes on substituted elements
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 replace
> > part of the expression itself (rather than the whole thing). But, maybe that
> > isn't really necessary? Maybe the evaluaton of the "shale:managed-bean" part
> > of the following expression could return the real managed bean *instance*,
> > instead of just it's name? Then you'd just use:
> >
> > set name="action" value="#{shale:managed-bean.saveAction}"/>
> >
> > on a button component, without needing any textual substitution of the
> > expression itself.
> >
>
> Ok, I see what you mean now. That looks good, has some style.
>
Agreed, I'm afraid I was a little lost in all the @ signs that were
previously around, it almost seemed to be another programming model. I
see this has the benefit of having the look and feel of EL with a
couple of implicit maps to refer to Shale managed beans and
attributes. Feels like home.
> > 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 there was really a value there, or we could do a "set
> > if" operation that only performed the set if the expression evaluated to
> > something other than null or empty string:
> >
> >
> >
> > where the expression would evaluate the value of the "class" attribute, if
> > it exists, and perform the set only if a non-null non-empty-string value was
> > returned by evaluating the expression.
> >
>
> That's a interesting idea. Or, we might be able to use a new "bindingType"
> in the "set" node. But, a "set-if" might be more descriptive.
>
Does that mean there are scenarios where one wouldn't want the
behavior in Craig's first suggestions (a "smart" if)? If there aren't,
IMO, it makes sense to do that since this is one of the cases where
less is more and not having to remember to differentiate between
and is a good thing while authoring.
-Rahul
> > Craig
> >
>
> Gary
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale][clay] CSS style classes on substituted elements
> > >
> > > 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 head, maybe something like:
> > >
> > > #{shale:attribute.managed-bean-name}
> > >
> > > or
> > >
> > > #{shale:attribute.class}
> > >
> > > ?
> >
> > I like the looks of that but how would we handle the managed bean name?
> > #{#{shale:attribute.managed-bean-name}.address1}
>
>
> 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 replace
> part of the expression itself (rather than the whole thing). But, maybe that
> isn't really necessary? Maybe the evaluaton of the "shale:managed-bean" part
> of the following expression could return the real managed bean *instance*,
> instead of just it's name? Then you'd just use:
>
> set name="action" value="#{shale:managed-bean.saveAction}"/>
>
> on a button component, without needing any textual substitution of the
> expression itself.
>
Ok, I see what you mean now. That looks good, has some style.
> 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 there was really a value there, or we could do a "set
> if" operation that only performed the set if the expression evaluated to
> something other than null or empty string:
>
>
>
> where the expression would evaluate the value of the "class" attribute, if
> it exists, and perform the set only if a non-null non-empty-string value was
> returned by evaluating the expression.
>
That's a interesting idea. Or, we might be able to use a new "bindingType" in
the "set" node. But, a "set-if" might be more descriptive.
> Doing this kind of thing would require some interesting logic in the custom
> variable resolver and property resolver implementations, to allow evaluation
> of things like "shale:managed-bean" and "shale:attribute" to do the right
> things. But, storing context information in a thread-local variable would
> likely be up to the task.
>
The symbol info and the current attributte is already being pushed to the
Command context, ClayContext.
We could change the ClayContext to use thread scope.
> Hmm ... I wonder if we could eliminate the need to explain what
> "useValueLateBinding" is all about, using similar thinking?
>
I removed that silliness a few weeks ago and made it more like how the JSF
component attributes are described.
I replaced it with a bindingType attribute:
> Craig
>
Gary
Re: [shale][clay] CSS style classes on substituted elements
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 specified then the result will be >
> >
> > > > > class="@class"> Is that right, Gary?
> > > > > >
> > > > > >
> > > > > > Yes, it does do that :-(.
> > > > > >
> > > > > > One solution may be to set the value of the 'class' symbol in
> > > baseHtml
> > > > > to
> > > > > > > empty. So, in baseHtml you have > > value=""/>. Then have a
> > > > > conventional that attributes which
> > > > > > > resolve
> > > > > > > to an empty value are omitted. I really can't think of a case
> you
> > > > > would
> > > > > > > want
> > > > > > > an empty attribute value?
> > > > > >
> > > > > Only attributes that have a null value are ignored. This would be
> an
> > > > > attribute that was not given a value attribute. Maybe an empty
> string
> > > should
> > > > > also be ignored.
> > > > >
> > > > > >
> > > > > > I would want it not to emit the "output" attribute at all, if
> there
> > > was
> > > > > no
> > > > > > input attribute set. Wouldn't that make more sense?
> > > > > >
> > > > > Ya, currently it kind of works backwards from how you might
> normally
> > > think
> > > > > of symbol evaluation. The attribute value is scanned for know
> symbols.
> > > > > Maybe the value should be scanned for a symbol and then use the
> symbol
> > > > > table to lookup the replacement value. If not found, insert an
> empty
> > > string.
> > > > > This would be a more efficient way but it would require that we
> have a
> > > > > beginning and ending symbol delimiter. What about "@myvar@"? Two
> big
> > > O's in
> > > > > OOPs.
> > > > >
> > > >
> > > > I don't think inserting an empty string accomplishes what I'm after
> > > here,
> > > > does it? A zero length string would cause outputting
> > > >
> > > > class=""
> > > >
> > > > in the emitted HTML, which is not really any better than
> > > >
> > > > class="@class"
> > > >
> > > > that we get with the patch I just applied.
> > >
> > > In the PropertyValueCommand we could exit the command if the target
> > > attribute value was empty after the symbol replacement.
> > > String expr = replaceMnemonic(clayContext);
> > > if (expr.length() == 0) {
> > > return isFinal;
> > > }
> > >
> > > It would work for the example above but not for something like "
> > > color:@mycolor" which would return "color:".
> >
> >
> > Yep. A key question is whether we'd even want to support replacing
> *part* of
> > a value with something that was calculated, versus the whole thing. The
> > precedents in JSP space (you can't use a partial runtime expression in a
> > custom tag attribute value ... it's all or nothing) and in JSF space
> (same
> > thing with value binding expressions) would encourage not supporting
> > something like "color:@mycolor" (or, for that matter, "color:@mycolor
> @").
> >
> > >
> > > > I've also been thinking that the literal string "managed-bean-name"
> > > should
> > > > > become a symbol. Now it's inconsistent - the exception. All other
> > > symbols
> > > > > require an "@" delimiter.
> > > > >
> > > >
> > > > Agree with you about that ... and we might want to think about
> whether
> > > there
> > > > are any additional symbols that might merit being reserved from the
> > > get-go.
> > > > On that topic, it might even be better to use a compound name
> > > > ("@shale:managed-bean-name@" or maybe more economically
> "@shale:bean@)
> > > so
> > > > that we can avoid future name clashes if additional symbols are
> added
> > > later.
> > > >
> > >
> > > I like @shale:managed-bean-name@ since it's more like the faces XML
> > > schema.
> >
> >
> > Sounds good.
> >
> > What do you think about the double delimiter?
> >
> >
> > Pro: makes it clear where the identifier being replaced ends.
> >
> > Pro: lets us do literal+expression interleaving later, even if we don't
> > allow it at the beginning.
> >
> > Pro: more like other expressions (JSP, JSF) that have beginning and
> ending
> > delimiters.
> >
> > Con: disallows use of the delimiter character inside the expression,
> unless
> > we also invent an escaping syntax like a preceding "\" character.
> >
> > Con: one more character to type -- and no, that's not as serious an
> issue as
> > the pros :-).
> >
> > That being said, I'm also wondering if we could reuse the "#{...}"
> syntax
> > that people are already familiar with, by inventing some sort of
> variable
> > name that says "attribute name xxx on the component being replaced. That
> > way, you wouldn't have to learn a new syntax, and you'd be able to use
> more
> > complicated expressions than just variable replacement.
> >
> > This will become even more important in a JSF 1.2 world, because the EL
> > expression evaluation machinery has been pull
Re: [shale][clay] CSS style classes on substituted elements
> >
> > > 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 right, Gary?
> > > > >
> > > > >
> > > > > Yes, it does do that :-(.
> > > > >
> > > > > One solution may be to set the value of the 'class' symbol in
> > baseHtml
> > > > to
> > > > > > empty. So, in baseHtml you have > > value=""/>. Then have a
> > > > conventional that attributes which
> > > > > > resolve
> > > > > > to an empty value are omitted. I really can't think of a case you
> > > > would
> > > > > > want
> > > > > > an empty attribute value?
> > > > >
> > > > Only attributes that have a null value are ignored. This would be an
> > > > attribute that was not given a value attribute. Maybe an empty string
> > should
> > > > also be ignored.
> > > >
> > > > >
> > > > > I would want it not to emit the "output" attribute at all, if there
> > was
> > > > no
> > > > > input attribute set. Wouldn't that make more sense?
> > > > >
> > > > Ya, currently it kind of works backwards from how you might normally
> > think
> > > > of symbol evaluation. The attribute value is scanned for know symbols.
> > > > Maybe the value should be scanned for a symbol and then use the symbol
> > > > table to lookup the replacement value. If not found, insert an empty
> > string.
> > > > This would be a more efficient way but it would require that we have a
> > > > beginning and ending symbol delimiter. What about "@myvar@"? Two big
> > O's in
> > > > OOPs.
> > > >
> > >
> > > I don't think inserting an empty string accomplishes what I'm after
> > here,
> > > does it? A zero length string would cause outputting
> > >
> > > class=""
> > >
> > > in the emitted HTML, which is not really any better than
> > >
> > > class="@class"
> > >
> > > that we get with the patch I just applied.
> >
> > In the PropertyValueCommand we could exit the command if the target
> > attribute value was empty after the symbol replacement.
> > String expr = replaceMnemonic(clayContext);
> > if (expr.length() == 0) {
> > return isFinal;
> > }
> >
> > It would work for the example above but not for something like "
> > color:@mycolor" which would return "color:".
>
>
> Yep. A key question is whether we'd even want to support replacing *part* of
> a value with something that was calculated, versus the whole thing. The
> precedents in JSP space (you can't use a partial runtime expression in a
> custom tag attribute value ... it's all or nothing) and in JSF space (same
> thing with value binding expressions) would encourage not supporting
> something like "color:@mycolor" (or, for that matter, "color:@mycolor@").
>
> >
> > > I've also been thinking that the literal string "managed-bean-name"
> > should
> > > > become a symbol. Now it's inconsistent - the exception. All other
> > symbols
> > > > require an "@" delimiter.
> > > >
> > >
> > > Agree with you about that ... and we might want to think about whether
> > there
> > > are any additional symbols that might merit being reserved from the
> > get-go.
> > > On that topic, it might even be better to use a compound name
> > > ("@shale:managed-bean-name@" or maybe more economically "@shale:bean@)
> > so
> > > that we can avoid future name clashes if additional symbols are added
> > later.
> > >
> >
> > I like @shale:managed-bean-name@ since it's more like the faces XML
> > schema.
>
>
> Sounds good.
>
> What do you think about the double delimiter?
>
>
> Pro: makes it clear where the identifier being replaced ends.
>
> Pro: lets us do literal+expression interleaving later, even if we don't
> allow it at the beginning.
>
> Pro: more like other expressions (JSP, JSF) that have beginning and ending
> delimiters.
>
> Con: disallows use of the delimiter character inside the expression, unless
> we also invent an escaping syntax like a preceding "\" character.
>
> Con: one more character to type -- and no, that's not as serious an issue as
> the pros :-).
>
> That being said, I'm also wondering if we could reuse the "#{...}" syntax
> that people are already familiar with, by inventing some sort of variable
> name that says "attribute name xxx on the component being replaced. That
> way, you wouldn't have to learn a new syntax, and you'd be able to use more
> complicated expressions than just variable replacement.
>
> 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 head, maybe something like:
>
> #{shale:attribute.managed-bean-name}
>
> or
>
> #{shale:
Re: [shale][clay] CSS style classes on substituted elements
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 specified then the result will be > >
> > > class="@class"> Is that right, Gary?
> > > >
> > > >
> > > > Yes, it does do that :-(.
> > > >
> > > > One solution may be to set the value of the 'class' symbol in
> baseHtml
> > > to
> > > > > empty. So, in baseHtml you have > > value=""/>. Then have a
> > > conventional that attributes which
> > > > > resolve
> > > > > to an empty value are omitted. I really can't think of a case you
> > > would
> > > > > want
> > > > > an empty attribute value?
> > > >
> > > Only attributes that have a null value are ignored. This would be an
> > > attribute that was not given a value attribute. Maybe an empty string
> should
> > > also be ignored.
> > >
> > > >
> > > > I would want it not to emit the "output" attribute at all, if there
> was
> > > no
> > > > input attribute set. Wouldn't that make more sense?
> > > >
> > > Ya, currently it kind of works backwards from how you might normally
> think
> > > of symbol evaluation. The attribute value is scanned for know symbols.
> > > Maybe the value should be scanned for a symbol and then use the symbol
> > > table to lookup the replacement value. If not found, insert an empty
> string.
> > > This would be a more efficient way but it would require that we have a
> > > beginning and ending symbol delimiter. What about "@myvar@"? Two big
> O's in
> > > OOPs.
> > >
> >
> > I don't think inserting an empty string accomplishes what I'm after
> here,
> > does it? A zero length string would cause outputting
> >
> > class=""
> >
> > in the emitted HTML, which is not really any better than
> >
> > class="@class"
> >
> > that we get with the patch I just applied.
>
> In the PropertyValueCommand we could exit the command if the target
> attribute value was empty after the symbol replacement.
> String expr = replaceMnemonic(clayContext);
> if (expr.length() == 0) {
> return isFinal;
> }
>
> It would work for the example above but not for something like "
> color:@mycolor" which would return "color:".
Yep. A key question is whether we'd even want to support replacing *part* of
a value with something that was calculated, versus the whole thing. The
precedents in JSP space (you can't use a partial runtime expression in a
custom tag attribute value ... it's all or nothing) and in JSF space (same
thing with value binding expressions) would encourage not supporting
something like "color:@mycolor" (or, for that matter, "color:@mycolor@").
>
> > I've also been thinking that the literal string "managed-bean-name"
> should
> > > become a symbol. Now it's inconsistent - the exception. All other
> symbols
> > > require an "@" delimiter.
> > >
> >
> > Agree with you about that ... and we might want to think about whether
> there
> > are any additional symbols that might merit being reserved from the
> get-go.
> > On that topic, it might even be better to use a compound name
> > ("@shale:managed-bean-name@" or maybe more economically "@shale:bean@)
> so
> > that we can avoid future name clashes if additional symbols are added
> later.
> >
>
> I like @shale:managed-bean-name@ since it's more like the faces XML
> schema.
Sounds good.
What do you think about the double delimiter?
Pro: makes it clear where the identifier being replaced ends.
Pro: lets us do literal+expression interleaving later, even if we don't
allow it at the beginning.
Pro: more like other expressions (JSP, JSF) that have beginning and ending
delimiters.
Con: disallows use of the delimiter character inside the expression, unless
we also invent an escaping syntax like a preceding "\" character.
Con: one more character to type -- and no, that's not as serious an issue as
the pros :-).
That being said, I'm also wondering if we could reuse the "#{...}" syntax
that people are already familiar with, by inventing some sort of variable
name that says "attribute name xxx on the component being replaced. That
way, you wouldn't have to learn a new syntax, and you'd be able to use more
complicated expressions than just variable replacement.
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 head, maybe something like:
#{shale:attribute.managed-bean-name}
or
#{shale:attribute.class}
?
Craig
> Any objections to:
> > > 1) requiring a begin and end delimiter for symbols,
> > > 2) making the managed bean name a symbol,
> > > 3) ignoring empty string attributes and
> > > 4) changing the symbol replacement method?
> > > > Craig
> > > >
> > > Gary
> > >
> >
> > Craig
> >
>
Re: [shale][clay] CSS style classes on substituted elements
> 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 right, Gary?
> > >
> > >
> > > Yes, it does do that :-(.
> > >
> > > One solution may be to set the value of the 'class' symbol in baseHtml
> > to
> > > > empty. So, in baseHtml you have > > value=""/>. Then have a
> > conventional that attributes which
> > > > resolve
> > > > to an empty value are omitted. I really can't think of a case you
> > would
> > > > want
> > > > an empty attribute value?
> > >
> > Only attributes that have a null value are ignored. This would be an
> > attribute that was not given a value attribute. Maybe an empty string
> > should
> > also be ignored.
> >
> > >
> > > I would want it not to emit the "output" attribute at all, if there was
> > no
> > > input attribute set. Wouldn't that make more sense?
> > >
> > Ya, currently it kind of works backwards from how you might normally think
> > of symbol evaluation. The attribute value is scanned for know symbols.
> > Maybe the value should be scanned for a symbol and then use the symbol
> > table to lookup the replacement value. If not found, insert an empty
> > string.
> > This would be a more efficient way but it would require that we have a
> > beginning and ending symbol delimiter. What about "@myvar@"? Two big O's in
> > OOPs.
> >
>
> I don't think inserting an empty string accomplishes what I'm after here,
> does it? A zero length string would cause outputting
>
> class=""
>
> in the emitted HTML, which is not really any better than
>
> class="@class"
>
> that we get with the patch I just applied.
In the PropertyValueCommand we could exit the command if the target attribute
value was empty after the symbol replacement.
String expr = replaceMnemonic(clayContext);
if (expr.length() == 0) {
return isFinal;
}
It would work for the example above but not for something like "color:@mycolor"
which would return "color:".
>
> I've also been thinking that the literal string "managed-bean-name" should
> > become a symbol. Now it's inconsistent - the exception. All other symbols
> > require an "@" delimiter.
> >
>
> Agree with you about that ... and we might want to think about whether there
> are any additional symbols that might merit being reserved from the get-go.
> On that topic, it might even be better to use a compound name
> ("@shale:managed-bean-name@" or maybe more economically "@shale:bean@) so
> that we can avoid future name clashes if additional symbols are added later.
>
I like @shale:managed-bean-name@ since it's more like the faces XML schema.
What do you think about the double delimiter?
> Any objections to:
> > 1) requiring a begin and end delimiter for symbols,
> > 2) making the managed bean name a symbol,
> > 3) ignoring empty string attributes and
> > 4) changing the symbol replacement method?
> > > Craig
> > >
> > Gary
> >
>
> Craig
>
Re: [shale][clay] CSS style classes on substituted elements
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, Gary?
> >
> >
> > Yes, it does do that :-(.
> >
> > One solution may be to set the value of the 'class' symbol in baseHtml
> to
> > > empty. So, in baseHtml you have > > value=""/>. Then have a
> conventional that attributes which
> > > resolve
> > > to an empty value are omitted. I really can't think of a case you
> would
> > > want
> > > an empty attribute value?
> >
> Only attributes that have a null value are ignored. This would be an
> attribute that was not given a value attribute. Maybe an empty string should
> also be ignored.
>
> >
> > I would want it not to emit the "output" attribute at all, if there was
> no
> > input attribute set. Wouldn't that make more sense?
> >
> Ya, currently it kind of works backwards from how you might normally think
> of symbol evaluation. The attribute value is scanned for know symbols.
> Maybe the value should be scanned for a symbol and then use the symbol
> table to lookup the replacement value. If not found, insert an empty string.
> This would be a more efficient way but it would require that we have a
> beginning and ending symbol delimiter. What about "@myvar@"? Two big O's in
> OOPs.
>
I don't think inserting an empty string accomplishes what I'm after here,
does it? A zero length string would cause outputting
class=""
in the emitted HTML, which is not really any better than
class="@class"
that we get with the patch I just applied.
I've also been thinking that the literal string "managed-bean-name" should
> become a symbol. Now it's inconsistent - the exception. All other symbols
> require an "@" delimiter.
>
Agree with you about that ... and we might want to think about whether there
are any additional symbols that might merit being reserved from the get-go.
On that topic, it might even be better to use a compound name
("@shale:managed-bean-name@" or maybe more economically "@shale:bean@) so
that we can avoid future name clashes if additional symbols are added later.
Any objections to:
> 1) requiring a begin and end delimiter for symbols,
> 2) making the managed bean name a symbol,
> 3) ignoring empty string attributes and
> 4) changing the symbol replacement method?
> > Craig
> >
> Gary
>
Craig
Re: [shale][clay] CSS style classes on substituted elements
> > > > 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 be to set the value of the 'class' symbol in baseHtml to > > empty. So, in baseHtml you have > > value=""/>. Then have a conventional > > that attributes which > > resolve > > to an empty value are omitted. I really can't think of a case you would > > want > > an empty attribute value? > Only attributes that have a null value are ignored. This would be an attribute that was not given a value attribute. Maybe an empty string should also be ignored. > > I would want it not to emit the "output" attribute at all, if there was no > input attribute set. Wouldn't that make more sense? > Ya, currently it kind of works backwards from how you might normally think of symbol evaluation. The attribute value is scanned for know symbols. Maybe the value should be scanned for a symbol and then use the symbol table to lookup the replacement value. If not found, insert an empty string. This would be a more efficient way but it would require that we have a beginning and ending symbol delimiter. What about "@myvar@"? Two big O's in OOPs. I've also been thinking that the literal string "managed-bean-name" should become a symbol. Now it's inconsistent - the exception. All other symbols require an "@" delimiter. Any objections to: 1) requiring a begin and end delimiter for symbols, 2) making the managed bean name a symbol, 3) ignoring empty string attributes and 4) changing the symbol replacement method? > Craig > Gary
Re: [shale][clay] CSS style classes on substituted elements
On 11/4/05, Ryan Wynn <[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, Gary?
Yes, it does do that :-(.
One solution may be to set the value of the 'class' symbol in baseHtml to
> empty. So, in baseHtml you have value=""/>. Then have a conventional that attributes which
> resolve
> to an empty value are omitted. I really can't think of a case you would
> want
> an empty attribute value?
I would want it not to emit the "output" attribute at all, if there was no
input attribute set. Wouldn't that make more sense?
Craig
On 11/3/05, Gary VanMatre <[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
> > Date: Thu, 3 Nov 2005 22:54:38 +
> > Subject: Re: [shale][clay] CSS style classes on substituted elements
> > 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
> > developer views.
> > On the other hand if you wanted to utilize the new symbol functionality.
> > You would change
> > your clay-config.xml to add the following:
> >
> >
> > ...
> >
> >
> >
> > Then you could just use
> >
> > username error message
> >
> > in the html and still get the proper output in both designer and
> developer
> > views.
> >
> > On 11/3/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> > >
> > > 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
> > > login.html I changed:
> > >
> > >
> > > username error message
> > >
> > >
> > > to the following instead ("errors" is a CSS style class that turns the
> > > text
> > > red):
> > >
> > >
> > > username error message
> > >
> > >
> > > When you redisplay the designer view, this does indeed show a change
> in
> > > behavior -- the "username error message" string shows up in red.
> > However,
> > > if
> > > you redisplay the developer view and then try to enter an invalid
> > > username/password, the text still comes up in black. One thing I
> > noticed,
> > > in
> > > the emitted HTML markup for the developer view, the error message
> string
> > > is
> > > *not* surrounded by a
Re: [shale][clay] CSS style classes on substituted elements
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 Is that right, Gary?
One solution may be to set the value of the 'class' symbol in baseHtml to
empty. So, in baseHtml you have . Then have a conventional that attributes which resolve
to an empty value are omitted. I really can't think of a case you would want
an empty attribute value?
On 11/3/05, Gary VanMatre <[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
> Date: Thu, 3 Nov 2005 22:54:38 +
> Subject: Re: [shale][clay] CSS style classes on substituted elements
> 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
> developer views.
> On the other hand if you wanted to utilize the new symbol functionality.
> You would change
> your clay-config.xml to add the following:
>
>
> ...
>
>
>
> Then you could just use
>
> username error message
>
> in the html and still get the proper output in both designer and developer
> views.
>
> On 11/3/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> >
> > 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
> > login.html I changed:
> >
> >
> > username error message
> >
> >
> > to the following instead ("errors" is a CSS style class that turns the
> > text
> > red):
> >
> >
> > username error message
> >
> >
> > When you redisplay the designer view, this does indeed show a change in
> > behavior -- the "username error message" string shows up in red.
> However,
> > if
> > you redisplay the developer view and then try to enter an invalid
> > username/password, the text still comes up in black. One thing I
> noticed,
> > in
> > the emitted HTML markup for the developer view, the error message string
> > is
> > *not* surrounded by a
Re: [shale][clay] CSS style classes on substituted elements
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 a h:message, then
username error message
would produce ... in both the designer and
developer views.
On the other hand if you wanted to utilize the new symbol functionality.
You would change
your clay-config.xml to add the following:
...
Then you could just use
username error message
in the html and still get the proper output in both designer and developer
views.
On 11/3/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
>
> 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
> login.html I changed:
>
>
> username error message
>
>
> to the following instead ("errors" is a CSS style class that turns the
> text
> red):
>
>
> username error message
>
>
> When you redisplay the designer view, this does indeed show a change in
> behavior -- the "username error message" string shows up in red. However,
> if
> you redisplay the developer view and then try to enter an invalid
> username/password, the text still comes up in black. One thing I noticed,
> in
> the emitted HTML markup for the developer view, the error message string
> is
> *not* surrounded by a
Re: [shale][clay] CSS style classes on substituted elements
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) use the "styleClass" --> "class" trick, so this
will fix 'em all.
Thanks Ryan!
Craig
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, 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
> > developer views.
> > On the other hand if you wanted to utilize the new symbol functionality.
> > You would change
> > your clay-config.xml to add the following:
> >
> >
> > ...
> >
> >
> >
> > Then you could just use
> >
> > username error message
> >
> > in the html and still get the proper output in both designer and
> > developer views.
> >
> > On 11/3/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> > >
> > > 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
> > > login.html I changed:
> > >
> > >
> > > username error message
> > >
> > >
> > > to the following instead ("errors" is a CSS style class that turns the
> > > text
> > > red):
> > >
> > >
> > > username error message
> > >
> > >
> > > When you redisplay the designer view, this does indeed show a change
> in
> > > behavior -- the "username error message" string shows up in red.
> > > However, if
> > > you redisplay the developer view and then try to enter an invalid
> > > username/password, the text still comes up in black. One thing I
> > > noticed, in
> > > the emitted HTML markup for the developer view, the error message
> string
> > > is
> > > *not* surrounded by a
Re: [shale][clay] CSS style classes on substituted elements
>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
>login.html I changed:
>
>
>username error message
>
>
>to the following instead ("errors" is a CSS style class that turns the text
>red):
>
>
>username error message
>
>
>When you redisplay the designer view, this does indeed show a change in
>behavior -- the "username error message" string shows up in red. However, if
>you redisplay the developer view and then try to enter an invalid
>username/password, the text still comes up in black. One thing I noticed, in
>the emitted HTML markup for the developer view, the error message string is
>*not* surrounded by a
In addition, any HTML element can be bound to a component using the jsfid.
Implicit mappings can be overridden by providing a jsfid binding in the html.
The reserved "ignore" jsfid can also be use to ignore the implied mapping.
This would be handy for J2EE form authentication.
Another recent change made any HTML attribute that is not mapped to a bound
component attribute a symbol. Symbols allow you to change a component
definition without extending it. For example the html attribute "class" is
not defined in the "usernameMessage" class so it becomes a symbol. The
attribute value of "styleClass" is replaced with the value of the symbol.
HTML:
username error message
XML:
>I'd be fine with some alternative way of accomplishing this sort of
>demonstration, but changing the HTML template and seeing the change applied
>immediately is a more compelling demo than something like changing
>clay-config.html.
>
The mapping between the HTML elements to the JSF component is now direct. We
talked about creating a pluggable mapper similar to the ViewController to
managed bean name but didn't get it done.
>Craig
Gary
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale][clay] CSS style classes on substituted elements
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, 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
> developer views.
> On the other hand if you wanted to utilize the new symbol functionality.
> You would change
> your clay-config.xml to add the following:
>
>
> ...
>
>
>
> Then you could just use
>
> username error message
>
> in the html and still get the proper output in both designer and
> developer views.
>
> On 11/3/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> >
> > 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
> > login.html I changed:
> >
> >
> > username error message
> >
> >
> > to the following instead ("errors" is a CSS style class that turns the
> > text
> > red):
> >
> >
> > username error message
> >
> >
> > When you redisplay the designer view, this does indeed show a change in
> > behavior -- the "username error message" string shows up in red.
> > However, if
> > you redisplay the developer view and then try to enter an invalid
> > username/password, the text still comes up in black. One thing I
> > noticed, in
> > the emitted HTML markup for the developer view, the error message string
> > is
> > *not* surrounded by a
Re: [shale][clay] CSS style classes on substituted elements
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
developer views.
On the other hand if you wanted to utilize the new symbol functionality.
You would change
your clay-config.xml to add the following:
...
Then you could just use
username error message
in the html and still get the proper output in both designer and developer
views.
On 11/3/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
>
> 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
> login.html I changed:
>
>
> username error message
>
>
> to the following instead ("errors" is a CSS style class that turns the
> text
> red):
>
>
> username error message
>
>
> When you redisplay the designer view, this does indeed show a change in
> behavior -- the "username error message" string shows up in red. However,
> if
> you redisplay the developer view and then try to enter an invalid
> username/password, the text still comes up in black. One thing I noticed,
> in
> the emitted HTML markup for the developer view, the error message string
> is
> *not* surrounded by a
Re: [shale][clay] CSS style classes on substituted elements
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 developers worrying about the
look and feel - which is what I'm trying to avoid by using Clay in the
first place.
On 11/3/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> 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
> login.html I changed:
>
>
> username error message
>
>
> to the following instead ("errors" is a CSS style class that turns the text
> red):
>
>
> username error message
>
>
> When you redisplay the designer view, this does indeed show a change in
> behavior -- the "username error message" string shows up in red. However, if
> you redisplay the developer view and then try to enter an invalid
> username/password, the text still comes up in black. One thing I noticed, in
> the emitted HTML markup for the developer view, the error message string is
> *not* surrounded by a
[shale][clay] CSS style classes on substituted elements
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
login.html I changed:
username error message
to the following instead ("errors" is a CSS style class that turns the text
red):
username error message
When you redisplay the designer view, this does indeed show a change in
behavior -- the "username error message" string shows up in red. However, if
you redisplay the developer view and then try to enter an invalid
username/password, the text still comes up in black. One thing I noticed, in
the emitted HTML markup for the developer view, the error message string is
*not* surrounded by a
