struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@apache.org>
Subject Re: [shale][clay] CSS style classes on substituted elements
Date Fri, 04 Nov 2005 23:44:51 GMT
On 11/4/05, Ryan Wynn <bigwynnr@gmail.com> wrote:
>
> 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?


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 <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?


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?

Craig

On 11/3/05, Gary VanMatre <gvanmatre@comcast.net> wrote:
> >
> > Ah, Ryan beat me to the answer. Figures, symbols was his idea anyway.
> >
> >
> >
> >
> >
> >
> >
> > ---------- Forwarded message ----------
> > From: Ryan Wynn <bigwynnr@gmail.com>
> > 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 <craigmcc@apache.org> 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: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message