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