I made a mistake copy paste the code of writeState. Actually looks like
this:
public void writeState(
FacesContext context,
StateManager.SerializedView serializedView) throws IOException
{
ResponseWriter rw = context.getResponseWriter();
rw.startElement("input", null);
rw.writeAttribute("type", "hidden", null);
rw.writeAttribute("name", VIEW_STATE_PARAM, null);
// Don't write out the ID, as it can be written
// out twice
// rw.writeAttribute("id", VIEW_STATE_PARAM, null);
String s = encodeSerializedViewAsString(serializedView);
rw.writeAttribute("value", s, null);
rw.endElement("input");
}
regards
Leonardo Uribe
On Wed, Jun 11, 2008 at 10:12 PM, Leonardo Uribe <[EMAIL PROTECTED]> wrote:
> Hi
>
> Checking some tomahawk stuff I have noted that when I'm using trinidad (any
> version 1.1 and 1.2) at the end of the form the hidden field that stores or
> references the state:
>
> <input type="hidden" name="javax.faces.ViewState"
>
> never render its id="javax.faces.ViewState" as myfaces and jsf ri does.
>
> the api javadoc of ResponseStateManager.isPostback says this:
>
> *The implementation if this method for the Standard HTML RenderKit must
> consult the
> ExternalContext<http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/javax/faces/context/ExternalContext.html>'s
> requestParameterMap and return true if and only if there is a key equal to
> the value of the symbolic constant
> VIEW_STATE_PARAM<http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/javax/faces/render/ResponseStateManager.html#VIEW_STATE_PARAM>
> .*
>
> *For backwards compatability with implementations of
> ResponseStateManagerprior to JSF 1.2, a default implementation is provided
> that consults the
> ExternalContext<http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/javax/faces/context/ExternalContext.html>'s
> requestParameterMap and return true if its size is greater than 0.*
>
> Trinidad implements its own ResponseStateManager like this:
>
> public class CoreResponseStateManager extends ResponseStateManager
> {
>
> /* ......code ....*/
> /**
> * Write the state into the page.
> * @todo Stream the resulting state into the page's content
> * instead of buffering it.
> * @todo Don't directly write out hidden input field; use an abstraction
> */
> @Override
> public void writeState(
> FacesContext context,
> StateManager.SerializedView serializedView) throws IOException
> {
> ResponseWriter rw = context.getResponseWriter();
> rw.startElement("input", null);
> rw.writeAttribute("type", "hidden", null);
> rw.writeAttribute("name", VIEW_STATE_PARAM, null);
> // Don't write out the ID, as it can be written
> // out twice
> rw.writeAttribute("id", VIEW_STATE_PARAM, null);
>
> String s = encodeSerializedViewAsString(serializedView);
> rw.writeAttribute("value", s, null);
>
> rw.endElement("input");
> }
>
> @Override
> /**
> * A request is a postback if it contains the state parameter.
> */
> public boolean isPostback(FacesContext context)
> {
> Map requestParams =
> context.getExternalContext().getRequestParameterMap();
> return requestParams.containsKey(VIEW_STATE_PARAM);
> }
>
> On trinidad 1.1 the commented code that render its id is missing.
>
> The problem start when some code uses javax.faces.ViewState to find if the
> request is a postback (trinidad has its own way to detect a postback using
> another input field). If the id is missing, that code thinks that every
> request is not a postback.
>
> The commented code says that the id is duplicated, but checking code
> nothing suggest that this is happening. I tried state saving client or
> server and no problems were found.
>
> I want to know if any developer has a reason to avoid render this id, and
> if no objections I'll commit this change in 72 hours (doing this
> s:inputSuggestAjax and s:tableSuggestAjax could work with trinidad and/or
> facelets and solve TOMAHAWK-1157).
>
> Suggestions are welcome
>
> regards
>
> Leonardo Uribe
>
>
>
