hah, and now, after further investigation I see that all this is unnecessary... I get a new session automatically for each new host i try to access my page from. I just assumed that the same session would be used. anyway, it was interesting to see how a persistance stategy was contributed.
2007/9/24, Ted Steen <[EMAIL PROTECTED]>: > 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 > -- /ted --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
