the contribution should be to the PersistentFieldManager of course

2007/9/24, Ted Steen <[EMAIL PROTECTED]>:
> Ok!
> After digging a little deeper I now see that extending the
> AbstractSessionPersistentFieldStrategy and letting the prefix contain
> the host name should be a solution!
> I then contribute this to the ApplicationStatePersistenceStrategySource.
> Any objections? :)
>
> 2007/9/24, Ted Steen <[EMAIL PROTECTED]>:
> > A page in our application can be in different states (depending on the
> > sub domain). When a field is persisted, the state of the page should
> > be taken in to account.
> >
> > For example if the page is accessed via the host name a.my-host.com
> > the page should have its fields persisted for the context A and if the
> > page is accessed via the host name b.my-host.com the fields should be
> > persisted for the context B.
> >
> > its important that if the user browses the page via a.my-host.com and
> > then changes to b.my-host.com the persistent fields should not cross
> > over!
> >
> > I am currently looking for a contribution to some sort of persist
> > stategy service but I'm not really sure where to look, and also, I'm
> > not really sure this is the right way.
> >
> > --
> > /ted
> >
>
>
> --
> /ted
>


-- 
/ted

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to