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
