On 11/17/05, Gary VanMatre <[EMAIL PROTECTED]> wrote:
> Rahul Akolkar wrote:
<snip/>
>
> I see the distinction as the Clay symbols can be used to create a new
> expression. This was the original vision for the "managed-bean-name" (We
> recently added the "@" delimiter for all other symbols). There are also
> cases that the symbol will just replace a literal value.
>
> "#{managed-bean-name.save}" --> "#{mybean.save}"
> or
> "@class" --> "myCSS"
>
<snap/>
>
> >
> >Why can't the new syntax do partial replacement? See above example in
> >JSP land, retrofit container evaluation -> symbol replacement, c:out
> >processing -> clay <set> processing.
> >
>
> If the target after the symbol replacement should be "#{mybean.save}",
> currently, you could do something like this [EMAIL PROTECTED]@savemethod}.
> How would you accomplish the same with the EL like syntax?
>
<snip/>
Note that this doesn't make the syntax EL-like -- you mention custom
property/variable resolvers and binding wrappers -- this makes it
*EL*. Looking through the archives, I think the origin of your
questions above comes from not having to trip over expressions that
turn into this:
#{...#{...}...}
In addition, IMO, it'd be nice if just by looking at the XML config,
it was reasonably clear to the reader that there are two passes in the
evaluation. Many XML-based syntaxes solve this issue by naming the
appropriate attribute "expr" instead of "value" (VoiceXML, for
instance). That way, the outer "#{" and "}" delimiters are implicit.
So, for the <set>, this fictitious expression:
value="[EMAIL PROTECTED]@bar}" (old)
becomes:
expr="#{foo-expr}.#{bar-expr}" (new)
Note after JSP 2.0, it is FUD that attribute values cannot be partial
EL expressions, even in JSP land. IMO, the second option above conveys
the two-pass evaluation scheme better so that as an author, it seems
clearer that I'm cons'ing an attribute value that is going to be
evaluated a second time.
The next question then, is what if after the first pass (or even
before that) we end up with a String literal. Most markup languages
that work on an ECMAScript-based platform will require you to quote
the expr attribute values in single quotes if the value is a String
literal.
expr=" ' #{foo-expr} ' " (new - no evaluation second pass - whitespace
for clarity)
expr=" ' foo ' " (new - no evaluation any pass - whitespace for clarity)
To sum it up:
Explicit token delimiter based expression languages will be fragile,
needing delimiter escapes & fancy footwork, and tend to lack
extensibility, though I agree this is definitely not true in the
examples today. I wouldn't be satisfied with symbol replacement the
way we manage it today *only* because the syntax seems to fulfill all
the current needs. This will commit clay to using this scheme for all
future releases. I don't believe anyone can guarantee how clay will
grow, and that the symbol replacement scheme used today will always be
adequate. OTOH, using a proven expression language, even though it may
need a few more keystrokes, gives you that peace of mind.
>
> Thanks for your comments and please take a look when you get some time. I
> haven't given up on the EL(ish) syntax yet but just haven't seen the light
> yet. I figured that this was one of the items we would want to wrap-up
> before the first cut.
>
And I mean to help, so while I'm not empassioned enough to keep
pushing on this, I'll leave you with this thought -
Innovation is often a burden.
Do you need the extra weight of a new evaluation/symbol replacement
language on your shoulders? Thanks for a patient ear ;-)
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
