>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 believe that at one time we might have been mapping the html attribute
"class" to the jsf attribute "styleClass". Recently, the html template parsing
was change to allow any attribute to be passed to the JSF component.
It is now open enough that you can use the html templates without needing
additional XML defintions - just the base definitions that is auto loaded.
This is demonstrated in the "Extreme HTML" rolodex use case.
This change also altered the method for mapping an html attribute to a JSF
component. It was a static array of attributes but now it is determined by the
attributes that are defined in the bound meta-component definition using the
jsfid attribute or the eleven implicitly mapped elements. Kind of similar to
the role of the TLD.
The eleven implicitly mapped elements that don't require a jsfid include:
<a>
<from>
<input type=text>
<input type=checkbox>
<input type=radio>
<input type=submit>
<label>
<select>
<select multiple>
<option>
<textarea>
In addition, any HTML element can be bound to a component using the jsfid.
Implicit mappings can be overridden by providing a jsfid binding in the html.
The reserved "ignore" jsfid can also be use to ignore the implied mapping.
This would be handy for J2EE form authentication.
<span jsfid="ignore">
<form method=post action=j_security_check>
<input type=text name=j_username>
<input type=text name=j_password>
</form>
</span>
Another recent change made any HTML attribute that is not mapped to a bound
component attribute a symbol. Symbols allow you to change a component
definition without extending it. For example the html attribute "class" is
not defined in the "usernameMessage" class so it becomes a symbol. The
attribute value of "styleClass" is replaced with the value of the symbol.
HTML:
<span jsfid="usernameMessage" class="errors">
username error message
</span>
XML:
<component jsfid="usernameMessage" extends="message" >
<attributes>
<set name="styleClass" value="@class"/>
</attributes>
</component>
>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.
>
The mapping between the HTML elements to the JSF component is now direct. We
talked about creating a pluggable mapper similar to the ViewController to
managed bean name but didn't get it done.
>Craig
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
