You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Ted Steen <te...@gmail.com> on 2007/09/24 09:17:06 UTC
T5: Persisting per page AND depending on page state.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Persisting per page AND depending on page state.
Posted by Jean-Philippe Bouchard <je...@mail.mcgill.ca>.
Probably because the domain component of the cookie issued by the
servlet container is the actual hostname, not .my-host.com
(http://wp.netscape.com/newsref/std/cookie_spec.html).
Anyhow, if you ever need to share the session, you'll know where to look :)
Ted Steen wrote:
> 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 <te...@gmail.com>:
>> the contribution should be to the PersistentFieldManager of course
>>
>> 2007/9/24, Ted Steen <te...@gmail.com>:
>>> 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 <te...@gmail.com>:
>>>> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Persisting per page AND depending on page state.
Posted by Ted Steen <te...@gmail.com>.
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 <te...@gmail.com>:
> the contribution should be to the PersistentFieldManager of course
>
> 2007/9/24, Ted Steen <te...@gmail.com>:
> > 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 <te...@gmail.com>:
> > > 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Persisting per page AND depending on page state.
Posted by Ted Steen <te...@gmail.com>.
the contribution should be to the PersistentFieldManager of course
2007/9/24, Ted Steen <te...@gmail.com>:
> 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 <te...@gmail.com>:
> > 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Persisting per page AND depending on page state.
Posted by Ted Steen <te...@gmail.com>.
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 <te...@gmail.com>:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org