Rahul Akolkar wrote: >Gary- > >First of all, thanks for all your work around clay. >
Thanks! >Since I mentioned I like the "new" syntax, here is my 2c worth (old >and new are subjective, what you call the old syntax is really new to >me, for example ;-): > Indeed, you are a skilled negotiator :-) >To set the context for my email, consider this JSP 2.0 page: > >-- BEGIN JSP -- ><%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%> ><c:set var="greater" value=">" /> ><c:out value="2 ${greater} 1" /> >-- END JSP -- > >Output rendered is a String "2 > 1" > >I'd like to point out two things: >1) Two pass evaluation (container gets first crack and yields "2 > 1", >c:out further mods it to "2 > 1") >2) Partial replacement happened before c:out got to processing the >value attribute > >I meant to project a similar approach to the syntax for clay symbols. > >Now, allow me to re-arrange your observations: > >> The old syntax resolves the expression before EL binding so exceptions report >>the expression post symbol merger. ><snip/> > >I never thought the new syntax would replace the two-pass expression >evaluation into a single pass, just like if you need a true second >order function, trying to replace with first order functions is a vain >exercise. In my mind, this was a fairly superficial change to the >syntax, not really requiring major surgery to the internals of the >two-pass eval impl. > 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" >> The new syntax would not allow for partial replacement. ><snip/> > >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? >> The old syntax is foreign but allows for partial replacement. ><snap/> > >A note about foreign syntax: The EL part of the JSP 2.0 specification >goes to some length to convince the reader that EL was needed, when >expression languages like XPath and ECMAScript existed. Similarly, as >a new clay user, I'd want to know why I'm being subjected to a new >syntax (and to that end, the examples like we're fleshing out right >now, are a great help). > Yep, I see your point on delivering a consistent message and aggree on the collaborative effort. >> The new syntax would be more EL like but would require a custom property >>resolver. >> The new syntax would require creating a wrapper Method and Value binding >> >>to hold the symbols overrides. ><snip/> > >Seems like it, and I'll take your word for it (I'd like to take a look >at that code for my own sake anyway, if I find some cycles over the >weekend). > Cool, suggestions are much appreciated. > > >> Well, I'm kind of hedging toward the older syntax. Any thought? ><snip/> > >The ones above :-) Anyway, am not an active clay user (yet), so my >opinion is less valuable than yours or Ryan's. Just wanted to follow >up on my earlier note about the two syntax versions. > 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. >-Rahul >> >> Gary >> Gary
