> >
> > > 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}
>
> ?
I like the looks of that but how would we handle the managed bean name?
#{#{shale:attribute.managed-bean-name}.address1}
Or, should we leave it #{managed-bean-name.address1} and use the
#{shale:attribute.class} syntax for clay symbols? I saw this symbol
replacement as a layer on top of EL allowing more reuse in component binding.
If we subscribe to that, a different syntax might be better.
Gary
>
> 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
> > >
> >
