Reported by @edburns

from javaserverfaces-spec.

@edburns said:
This work is covered under RI issue 28
<https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=28>.

The javadoc needs to be ammended like this, accounting for things like not
mentioning hidden fields per-se since doing so is view technology specific.

ViewHandler.writeState()

Say something about generating the window id and storing it in the requestMap.
This will get called once for each form in the page, each time overwriting the
previous value. Note also that previously, this method was a no-op on the
server side case, but now it actually does something.

StateManager.saveSerializedView()

Currently the Sun RI uses this method to actually save the view if the saving
method is server. Doing so isn't specified as one of the responsibilities of
this method. Is that a problem? In any case, we should note that we get the
windowId from the requestMap and combine it with the viewId to create the
uniqueViewId. This is used to store the view in the server.

ResponseStateManager.writeState()

Currently the Sun RI for this method is a no-op if state saving is on the
server. Say that this must change and we must write out a hidden field
containing the windowId.

StateManager.restoreView()

State that if saving on the server, the windowId must be retrieved from the
hidden field and combined with the viewId to retrieve the view. The fix for
issue 28 has this method grabbing the hidden field value from the
requestParameterMap, but I don't think StateManager should be doing that.
Perhaps we can add a method ResponseStateManager.getWindowId(), but if we go
that far, perhaps we should expose the windowId concept more prominently.

from javaserverfaces-spec.

@edburns said:
Perhaps a more clean approach would be to make ResponseStateManager
responsible for generating the windowId, allowing the StateManager to
get access to it, and most importantly, grabbing it from the request
parameter during the restore phase.

I don't like how the current RI impl has StateManagerImpl poking into
the request Map. That's outside the StateManagerImpl's charter.

So, I'd like to suggest:

/**

• Return the window Id for the current view.
  *
• The default implementation must behave as follows:
  *
• Look in the requestParameterMap for the key
• ResponseStateManager.WINDOW_ID. If found, return it.
  *
• If not found, look in the requestMap for the key
• ResponseStateManager.WINDOW_ID. If found, return it.
  *
• If not found, generate a unique window id for this view, put it in the
• requestMap, and return it.
  */

public String ResponseStateManager.getWindowId(FacesContext context);

• This method would be called from ViewHandler.writeState() if we're
  saving state on the server, instead of having the ViewHandler generate
  the id directly.

• This method would be called from StateManager.saveSerializedView() if
  we're saving state on the server, instead of having the StateManager
  access the requestParameterMap directly.

• This method would be called from ResponseStateManager.writeState()
  instead of accessing the requestParameterMap directly.

• This method would be called from StateManager.restoreView() instead of
  accessing the requestParameterMap directly.

Another concern I have is who has the responsibility for combining the
viewId and the windowId? Currently this is StateManager, but is that ok?

from javaserverfaces-spec.

@edburns said:
take ownership.

from javaserverfaces-spec.

@edburns said:
StateManager.writeState() javadocs should be modified to note that the windowId
may be used in addition to the viewId for saving and restoring the view.

from javaserverfaces-spec.

@edburns said:
Note that in the initial page request case, the generated window id will not be
used if there is no form in the page. This is ok.

Also note that we're generating the windowId during the restoreView phase.

from javaserverfaces-spec.

jayashri said:
Hi Ed,
Two observations:
1. For the pages that have no form, we are going to save and retrieve the
view only based the viewId. The only method that is aware of whether a form is
present in the page or not is ViewHandler.writeState(). So this method needs to
take responsibility for calling the method that creates the windowId.
2. For the same reason in (1), getWindowId() shouldn't create a windowId if one
is not present in request because we don't want StateManager.serializedView() to
get a windowId for the case when there is no form. So looks like we would need
two methods.

Thanks

from javaserverfaces-spec.

@edburns said:
Hello Jayashri,

You are correct. Here is my revised proposal:

/**

• Look in the requestParameterMap for the key
• ResponseStateManager.WINDOW_ID. If found, return it, otherwise return
• null.
  */

public String ResponseStateManager.getWindowIdFromRequest(FacesContext context)

• This method would be called from StateManager.restoreView() instead of
  accessing the requestParameterMap directly.

/**

• Return the window Id for the current view.
  *
• The default implementation must behave as follows:
  *
• look in the requestMap for the key ResponseStateManager.WINDOW_ID. If
• found, return it.
  *
• If not found, generate a unique window id for this view, put it in the
• requestMap, and return it.
  */

public String ResponseStateManager.getWindowId(FacesContext context);

• This method would be called from ViewHandler.writeState() if we're
  saving state on the server, instead of having the ViewHandler generate
  the id directly. This is the first callsite for this method during
  the request processing lifecycle, and this is where we want the id to
  be generated.

• This method would be called from StateManager.saveSerializedView() if
  we're saving state on the server, instead of having the StateManager
  access the requestParameterMap directly.

from javaserverfaces-spec.

@edburns said:
up to p2

from javaserverfaces-spec.

@edburns said:
This is related to frames.

from javaserverfaces-spec.

@edburns said:
accept ownership

from javaserverfaces-spec.

@edburns said:
Fix for part one.

Issue: jsf-spec11

This change bundle modifies the javadoc for ViewHandler.restoreView() to
clarify what should happen in the initial request to
ViewHandler.restoreView().

SECTION: API Changes

M jsf-api/src/javax/faces/application/ViewHandler.java

• • If this is an
• • initial request to the faces system, this method must return
• • null.

SECTION: RI changes

M jsf-ri/src/com/sun/faces/application/ViewHandlerImpl.java

• implement the above spec change. Note that the systest called
  com.sun.faces.pathtest.PathTest exercises this code.

SECTION: API diffs

Index: jsf-api/src/javax/faces/application/ViewHandler.java

RCS file:
/cvs/javaserverfaces-sources/jsf-api/src/javax/faces/application/ViewHandler.java,v
retrieving revision 1.39
diff -u -r1.39 ViewHandler.java
— jsf-api/src/javax/faces/application/ViewHandler.java 5 Apr 2004 18:25:59
-0000 1.39
+++ jsf-api/src/javax/faces/application/ViewHandler.java 5 Nov 2004 15:50:24 -0000
@@ -172,10 +172,12 @@
/**

• Perform whatever actions are required to restore the view

• associated with the specified {@link FacesContext} and

  • • viewId. It may delegate to the restoreView
  • • of the associated {@link StateManager} to do the actual work of
  • • restoring the view. If there is no available state for the
  • • specified viewId, return null.

  • • viewId. It may delegate to the
  • • restoreView of the associated {@link StateManager}
  • • to do the actual work of restoring the view. If this is an
  • • initial request to the faces system, this method must return
  • • null. If there is no available state for the specified
  • • viewId, return null.

  • @param context {@link FacesContext}

  for the current request

• @param viewId the view identifier for the current request

SECTION: RI diffs

Index: jsf-ri/src/com/sun/faces/application/ViewHandlerImpl.java

RCS file:
/cvs/javaserverfaces-sources/jsf-ri/src/com/sun/faces/application/ViewHandlerImpl.java,v
retrieving revision 1.45
diff -u -r1.45 ViewHandlerImpl.java
— jsf-ri/src/com/sun/faces/application/ViewHandlerImpl.java 5 Aug 2004
20:02:19 -0000 1.45
+++ jsf-ri/src/com/sun/faces/application/ViewHandlerImpl.java 5 Nov 2004
15:50:26 -0000
@@ -204,7 +204,7 @@
viewId = convertViewId(context, viewId);
}

• // maping could be null if a non-faces request triggered

  • // mapping could be null if a non-faces request triggered
    // this response.
    if (extContext.getRequestPathInfo() == null && mapping != null &&
    isPrefixMapped(mapping)) { @@ -220,14 +220,19 @@ throw new FacesException(ioe); }

  } else {

• // this is necessary to allow decorated impls.

• ViewHandler outerViewHandler =

• context.getApplication().getViewHandler();

• String renderKitId =

• outerViewHandler.calculateRenderKitId(context);

• viewRoot = Util.getStateManager(context).restoreView(context,

• viewId,

• renderKitId);

  • // only try to restore the view if this is not an initial
  • // request
  • if (!extContext.getRequestParameterMap().isEmpty()) { + // this is necessary to allow decorated impls. + ViewHandler outerViewHandler = + context.getApplication().getViewHandler(); + String renderKitId = + outerViewHandler.calculateRenderKitId(context); + viewRoot = + Util.getStateManager(context).restoreView(context, + viewId, + renderKitId); + }

  }

return viewRoot;

from javaserverfaces-spec.

@edburns said:

On Mon, 17 Jan 2005 11:53:09 -0500, sean schofield said:

SS> To Whom It May Concern:
SS> I would suggest the following two changes to the inner class SerializedView:

SS> 1.) The class should be declared static. It has no need to reference
SS> the parent class and thus does not require the implicit refernce to
SS> StateManager. "Maintaining this reference costs time and space with no
SS> corresponding benefit" (Effective Java, p. 92).

SS> 2) Make this inner class implement serializable. Once the implicit
SS> reference is gone (via suggestion #1) this class will always be
SS> serializable. Both properties are supposed to contain serializable
SS> objects after all. This would allow implementations to store the
SS> Serialized View directly in the session (for server-side state
SS> management option .)

from javaserverfaces-spec.

@edburns said:

On Wed, 26 Jan 2005 19:53:34 -0500, sean schofield said:

SS> It has been pointed out to me (on the jsf forum) that my suggestion
SS> would technically break the interface. Classes that were compiled
SS> against the old version of the api would have to be recompiled. Not
SS> a big deal in my opinion, but just pointing that out.

from javaserverfaces-spec.

@edburns said:
status enact

from javaserverfaces-spec.

@edburns said:
Fix checked in.

from javaserverfaces-spec.

@edburns said:
Prepare to delete "spec" subcomponent.

from javaserverfaces-spec.

@edburns said:
Move all to 1.2

from javaserverfaces-spec.

anahata said:
Hey i ahave an legacy application where we have used JSF 1.1_01 and also we are using Tomhawk 1.1.3 and application server is Oracle ias.
I have attached the error_log.txt, which contains the exception from the application server logs.
I would appreciate if someone can suggest the solution for the same.

from javaserverfaces-spec.

anahata said:
I would really appreciate if someone can suggest a solution for the above mentioned problem.

from javaserverfaces-spec.

@manfredriem said:
Closing resolved issue out

from javaserverfaces-spec.

File: error_log.txt
Attached By: anahata

from javaserverfaces-spec.

This issue was imported from java.net JIRA JAVASERVERFACES_SPEC_PUBLIC-11

from javaserverfaces-spec.

Marked as fixed on Thursday, March 4th 2010, 6:09:26 am

from javaserverfaces-spec.