Adam Brod wrote:
>
> Thanks for your help!
Let us know know the outcome!
> *
> Adam Brod*/
> Product Development Team/
>
>
> Ryan.Lubke_at_Sun.COM wrote on 03/01/2007 04:52:16 PM:
>
> > Adam Brod wrote:
> > >
> > > Well, we store the current user id in ThreadLocal, so it is easy for
> > > my to get the current userId, get the current viewId from
> > > FacesContext. Ideally there would be a simple interface I could
> > > implement such as
> > >
> > > *public* *interface* ViewStatePersister {
> > > *public* *void* *persistSerializedView*(FacesContext
> facesContext,
> > > SerializedView view);
> > > *public* SerializedView *retrieveSerializedView*(FacesContext
> > > facesContext);
> > > }
> > >
> > > I could easily implement this interface to store and retrieve the
> > > SerializedView without messing with anything else in the Lifecycle.
> > >
> > > Does that give you an idea for how I'd like to do it? Or were you
> > > looking for more specific details?
> > You should be able to accomplish this extending StateManager [1]. If
> > you can keep everything straight between
> > requests, then you could probably avoid having to implement a custom
> > RenderKit/ResponseStateManager, if
> > you can still write content to the view to trigger the default postback
> > detection.
> >
> > The default lifecycle implementation will call
> > ResponseStateManager.isPostBack() in order to just reload
> > the view, or go through the full lifecycle (process validations, invoke
> > application etc.).
> >
> > The default implementation of ResponseStateManager.isPostBack() looks
> > like this:
> >
> > /** @see {_at_link
> > ResponseStateManager#isPostback(javax.faces.context.FacesContext)} */
> > @Override
> > public boolean isPostback(FacesContext context) {
> >
> > return context.getExternalContext().getRequestParameterMap().
> > containsKey(ResponseStateManager.VIEW_STATE_PARAM);
> >
> > }
> >
> > So your StateManager.writeState() would need to write the
> VIEW_STATE_PARAM
> > out as a hidden field.
> >
> >
> >
> > > *
> > > Adam Brod*/
> > > Product Development Team/
> > >
> > >
> > > Ryan.Lubke_at_Sun.COM wrote on 03/01/2007 01:59:11 PM:
> > >
> > > > Adam Brod wrote:
> > > > >
> > > > > Hi-
> > > > >
> > > > > I am interested in storing my JSF view state in a local cache
> - not
> > > > > the session nor client side. Is this very difficult to do?
> Is there
> > > > > a standard hook that I can implement to do this? Or would I
> need to
> > > > > hack around in the RI code?
> > > > Can you provide more details on how you think you would map a user
> > > to an
> > > > entry in the local cache?
> > > > Would it be similar to server side state saving where we write
> the map
> > > > key that contains the view information
> > > > to the client?
> > > >
> > > >
> > > > >
> > > > > Thanks for any tips.
> > > > > *
> > > > > Adam Brod*/
> > > > > Product Development Team/
> > > > > Disclaimer: This electronic mail and any attachments are
> > > > confidential and may be privileged. If you are not the intended
> > > > recipient, please notify the sender immediately by replying to this
> > > > email, and destroy all copies of this email and any attachments.
> > > Thank you.
> > > > >
> > > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> users-unsubscribe_at_javaserverfaces.dev.java.net
> > > > For additional commands, e-mail:
> users-help_at_javaserverfaces.dev.java.net
> > > >
> > > Disclaimer: This electronic mail and any attachments are
> > confidential and may be privileged. If you are not the intended
> > recipient, please notify the sender immediately by replying to this
> > email, and destroy all copies of this email and any attachments.
> Thank you.
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_javaserverfaces.dev.java.net
> > For additional commands, e-mail: users-help_at_javaserverfaces.dev.java.net
> >
> Disclaimer: This electronic mail and any attachments are confidential and may be privileged. If you are not the intended recipient, please notify the sender immediately by replying to this email, and destroy all copies of this email and any attachments. Thank you.
>
>