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