|
I've uncovered several issues with JSF 1.2 support.
1) The view root computes the next unique id differently, createUniqueId(). In the 1.1 version, the last generated sequence was not saved. Each time the view was restored the counter was reinitialized to zero. Under 1.2, the internal counter is restored. 2) The view root's UNIQUE_ID_PREFIX changed from id to j_id. This is used when generating unique id's. There is logic wired in the renderers that keys off the component id to determine if span tags should wrap the rendered markup. 3) JSP 1.2 has added a JspidComsumer that creates a unique id passed on to the component. JSP tags that implement this interfaces will always return the same id. The id is used to identify the corresponding component within the JSF component tree. This was added to allow dynamic changes to the structure of the component tree. 4) There are several component attributes that have been added. The view root and the label are a couple. 5) The dispatching logic from-view-id, to-view-id on a forward doesn't insist that the suffix of the request uri is changed to the javax.faces.DEFAULT_SUFFIX. So, if your target ends with ".faces", you end up in a infinite loop. You can argue that this is a stupid user trick anyway. It just behaves differently than 1.1. I've made a few changes addressing 1, 2, 3 and 5. The new clay configuration definitions need to be addressed. I'd like to find a way to generate these from the TLD. It sounded like Hermod Opstvedt had interest in created a maven mojo to handle this. I'm going to leave this ticket open to report on JSF 1.2 support as it progresses. BTW, Ryan, Glassfish rocks! Gary - glad to hear you like GlassFish. Let us know if you run into any snags with the JSF impl as your progress.
6) Added attribute "binding" support for Converters, Validators and Listeners - new feature added to 1.2 spec.
7) Under the new RI JSF version, the form state marker has changed. Added logic to look for yet another state marker? "com.sun.faces.saveStateFieldMarker" - RI 1.1 "<!--@@JSF_FORM_STATE_MARKER@@-->" - myfaces 1.1.x "~com.sun.faces.saveStateFieldMarker~" - RI 1.2 I'm going to close this ticket. I don't believe that we have solved all the JSF 1.2 integration issues but we have made a huge step in that direction. We will create new tickets going forward.
Thanks again Ryan. |
||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Clay examples from usecases demo output Sun's state field marker
> When testing the following Clay examples from the shale-usecases example
> application:
> Symbols - pages 1, 2, and 3
> Full HTML View
> Extreme HTML View
> Full XML View
> I see, at the end of the page, 'com.sun.faces.saveState.FieldMarker'.
> I don't see this when running the Clay JSP view.
> To reproduce: Deploy the shale-usecases application to a nightly build of
> GlassFish and run one of the examples mentioned above.
Clay has not been refactored to support JSF 1.2.
In JSF 1.1, the JSP "ViewTag" tag handles searching through the rendered
response stream replacing the "com.sun.faces.saveStateFieldMarker" marker
within the HTML form tag with the serialized client state as a hidden input
field. The marker is not standardized under 1.1 and is called "<!--
@@JSF_FORM_STATE_MARKER@@-->" in myfaces.
When using Clay full HTML or XML views, the Clay View handler has this
responsibility since the page doesn't have a JSP "ViewTag" tag.
From what I understand, JSF 1.2 moves this responsibility to the ViewHandler
and the marker name is standardized. JSF 1.2 also handles the interweaving of
non-JSF jsp with JSF component rendered output differently too.
We will have to address this issue when committing to support JSF 1.2.
Thanks for the feedback.