Thanks for your help!
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.