Ulrich,

This is informative thanks.  Regarding avoiding using the session - it's not
something I need to do at all costs - I am in the early stages of an
application design and want to ensure the session usage is kept to a minimum
as there may be a requirement to cluster at some stage - I had read that
clustering applications that relied on session state had performance
implications though perhaps if the amount of data retained in the session is
small this is not going to cause too much of an overhead.

Regards,
Jim.

-----Original Message-----
From: Ulrich Stärk [mailto:u...@spielviel.de]
Sent: 06 January 2010 15:06
To: Tapestry users
Subject: Re: Persisting state without HTTP Session


I forgot that in order to store the object until the result page is being
rendered, you'll need to
somehow persist it. That would happen in the session again. So this is not
an option for you.

By the way: why do you want to avoid using the session at all costs?

Uli

On 06.01.2010 15:07 schrieb Jim O'Callaghan:
> Thanks Ulrich.  Do you think it is realistic to have an entire application
> use this approach as a method for sharing state between pages?, i.e. every
> page is injected, or is there a downside to this?
>
> Regards,
> Jim.
>
> -----Original Message-----
> From: Ulrich Stärk [mailto:u...@spielviel.de]
> Sent: 06 January 2010 13:58
> To: Tapestry users
> Subject: Re: Persisting state without HTTP Session
>
>
> Use setters and the @InjectPage annotation.
>
> @InjectPage private MyPage resultpage;
>
> Object onActionFromSomeComponent()
> {
>     resultpage.setSomething(something);
>     return resultpage;
> }
>
> Uli
>
> On 06.01.2010 14:16 schrieb Jim O'Callaghan:
>> Hi,
>>
>> Can anyone advise on the preferred way of persisting state between pages
>> without using HTTP Session?  PageActivationContext using Object[] looks
>> promising but I don't want long urls (from serialized objects) and there
> is
>> more data to share than a defined number of keys - I'm looking for
> something
>> that uses POST params ...?  Thanks.
>>
>> Regards,
>> Jim.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Reply via email to