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