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}
> >
> > ?
>
> I like the looks of that but how would we handle the managed bean name?
> #{#{shale:attribute.managed-bean-name}.address1}
Note that my original example should probably have been
#{shale:managed-bean-name}
because we're not actually talking about an attribute here.
The issue you raise, of course, is that you're actually trying to replace
part of the expression itself (rather than the whole thing). But, maybe that
isn't really necessary? Maybe the evaluaton of the "shale:managed-bean" part
of the following expression could return the real managed bean *instance*,
instead of just it's name? Then you'd just use:
<set name="action" value="#{shale:managed-bean.saveAction}"/>
on a button component, without needing any textual substitution of the
expression itself.
For the class substitution case that conditionally sets styleClass only if
class is actually specified, either the <set> element would need to be smart
about knowing whether there was really a value there, or we could do a "set
if" operation that only performed the set if the expression evaluated to
something other than null or empty string:
<set-if name="styleClass" value="#{shale:attribute.class}"/>
where the expression would evaluate the value of the "class" attribute, if
it exists, and perform the set only if a non-null non-empty-string value was
returned by evaluating the expression.
Doing this kind of thing would require some interesting logic in the custom
variable resolver and property resolver implementations, to allow evaluation
of things like "shale:managed-bean" and "shale:attribute" to do the right
things. But, storing context information in a thread-local variable would
likely be up to the task.
Hmm ... I wonder if we could eliminate the need to explain what
"useValueLateBinding" is all about, using similar thinking?
Craig
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
> > > >
> > >
>
