Sorry for the late response ... been somewhat distracted by day job responsibilities, so I could only answer simple questions during compile cycles :-). A couple of comments below.
On 11/16/05, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > We had some discussion on changing the Clay symbols to make them more JSF > like. I wanted to regroup on this to make sure that this is something that > we want to change. > > The symbols allow customizing a subtree under the JSF component tree > without using inheritance. We described the differences as being horizontal > customization versus vertical. > > I'll give a refresher example from the ConfigTestCase. > > > http://svn.apache.org/viewcvs.cgi/struts/shale/trunk/clay-plugin/src/test/org/apache/shale/clay/config/ConfigTestCase.java?view=markup > public void testSymbolInheritance() > > Base XML config defines a style attribute where the value is a symbol. The > default value is also established. > > <component jsfid="baseSymbolLabel" extends="outputLabel" > allowBody="false"> > <attributes> > <set name="style" value="@mystyle"/> > </attributes> > <symbols> > <set name="mystyle" value="color:blue"/> > </symbols> > </component> > > > There are three ways to use symbols. > > 1) HTML: > > <label jsfid="baseSymbolLabel" allowBody="true" > mystyle="color:yellow">Label Text:</label> > > 2) JSP: > > <clay:clay jsfid="baseSymbolLabel" id="mySymbol"> > <clay:sybmol name="mystyle" value="blue"/> > </clay:clay> > > 3) XML: > <component jsfid="symbol2Label" extends="symbol1Label" allowBody="false"> > <symbols> > <set name="mystyle" value="color:red"/> > </symbols> > </component> > > <component jsfid="symbolPanel" extends="panelGrid"> > <element renderId="1" jsfid="symbol1Label" /> > <element renderId="2" jsfid="symbol1Label"> > <symbols > > <set name="mystyle" value="color:red"/> > </symbols> > </element> > </component> > > > > The current syntax allow for partial replacement. The symbol is replaced > prior to creating a binding expression. > > <set name="action" value="managed-bean-name.saveAction }"/> > <set name="action" value="@class"/> > <set name="action" value="[EMAIL PROTECTED]"/> > > We proposed that we make the syntax more JSF oriented. > > <set name="action" value="#{shale:managed-bean.saveAction }"/> > <set name="action" value="#{shale:attribute.class }"/> > <set name="action" value="#{shale:managed-bean.attribute.class}"/> > > > The new syntax would be more EL like but would require a custom property > resolver. > The new syntax would not allow for partial replacement. For output-only bindings, you can actually use expressions with operators, so you can accomplish partial replacement that way. (Same is true for partial replacement with the new syntax ... works only on output bindings). The new syntax would require creating a wrapper Method and Value binding to > hold the symbols overrides. > > The old syntax is foreign but allows for partial replacement. > The old syntax resolves the expression before EL binding so exceptions > report the expression post symbol merger. The old syntax will be more familiar to someone with a casual acquaintence with XSLT or XPath, because "@" is used to access attribute values in those environments. Well, I'm kind of hedging toward the older syntax. Any thought? I don't have a problem with supporting "either/or" ... the "@" syntax is certainly very convenient when you are hand typing the expressions, while the EL expressions are used elsewhere anyway, so users will already be familiar with it. What I do want to see, even if we keep the old syntax, is to make "set" always treat missing values the way we had started talking about for "set-if". That means, in my styleClass scenario: <component jsfid="baseHtml" componentType="override"> <attributes> ... <set name="styleClass" value="@class"/> ... </attributes> </component> we would *not* emit a styleClass attribute unless there was actually a class attribute actually specified on the input. Craig Gary >
