I noticed that Craig commited the <set name="styleClass" value="@class"/> 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 <span class="@class">...</span>. Is that right, Gary? One solution may be to set the value of the 'class' symbol in baseHtml to empty. So, in baseHtml you have <symbols><set name="class" value=""/></symbols>. 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?
On 11/3/05, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > Ah, Ryan beat me to the answer. Figures, symbols was his idea anyway. > > > > > > > > ---------- Forwarded message ---------- > From: Ryan Wynn <[EMAIL PROTECTED]> > To: Struts Users Mailing List <user@struts.apache.org> > Date: Thu, 3 Nov 2005 22:54:38 +0000 > Subject: Re: [shale][clay] CSS style classes on substituted elements > I believe that currently if the html attribute is not also an attribute on > the underlying component, then the html attribute will be treated as a > symbol. > So, in this case if userNameMessage is actually a h:message, then > <span jsfid="usernameMessage" class="errors" styleClass="errors"> > username error message > </span> > would produce <span class="errors">...</span> in both the designer and > developer views. > On the other hand if you wanted to utilize the new symbol functionality. > You would change > your clay-config.xml to add the following: > <component jsfid="usernameMessage"..> > <attributes> > ... > <set name="styleClass" value="@class"/> > </attributes> > </component> > Then you could just use > <span jsfid="usernameMessage" class="errors"> > username error message > </span> > in the html and still get the proper output in both designer and developer > views. > > On 11/3/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > > As part of my JavaOne session on Shale, I demo'd the fact that Clay lets > > you > > have two different views of the page: > > > > Designer view: http://localhost:8080/myapp/login.html > > > > Developer view: http://localhost:8080/myapp/login.faces > > > > To demonstrate that Clay was actually parsing the HTML template, in > > login.html I changed: > > > > <span jsfid="usernameMessage"> > > username error message > > </span> > > > > to the following instead ("errors" is a CSS style class that turns the > > text > > red): > > > > <span jsfid="usernameMessage" class="errors"> > > username error message > > </span> > > > > When you redisplay the designer view, this does indeed show a change in > > behavior -- the "username error message" string shows up in red. > However, > > if > > you redisplay the developer view and then try to enter an invalid > > username/password, the text still comes up in black. One thing I > noticed, > > in > > the emitted HTML markup for the developer view, the error message string > > is > > *not* surrounded by a <span class="errors>...</span>, which is (of > course) > > why the text didn't change color. Did some behavior change recently in > > this > > regard? > > > > I'd be fine with some alternative way of accomplishing this sort of > > demonstration, but changing the HTML template and seeing the change > > applied > > immediately is a more compelling demo than something like changing > > clay-config.html. > > > > Craig > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
