Re: Persisting state without HTTP Session
I agree that one should try to defer session creation as long as possible. But as soon as there is some state to persist, you shouldn't hesitate to use sessions. Session replication isn't necessarily a heavy thing. Have a look at Terracotta, which shines at making web session replication scale well. Combine this with sticky sessions, and you get the best of two worlds. Terracotta does only send replicated data to the nodes that actually demands it. See http://www.terracotta.org Olle Hallin Senior Java Developer and Architect olle.hal...@crisp.se www.crisp.se http://www.linkedin.com/in/ollehallin 2010/1/7 Thiago H. de Paula Figueiredo > Em Wed, 06 Jan 2010 13:36:31 -0200, Jim O'Callaghan > escreveu: > > > Thanks for the responses Thiago. >> > > You're welcome! > > I'll have a look at the >> LinkCreationListener you suggested in your other email. Regarding the >> response below, does the approach not make an assumption that the objects >> I am trying to share between pages are persisted objects with a >> key(id)/value elationship? I'm using something at the moment that manages a >> menu stack in the user's session and some other data that is really just >> relevant to >> >> the user's session and not something I had thought of persisting. >> > > The approach doesn't assume your objects have an id, but it does assume you > won't put much information in the URLs. Internet Explorer, for example, has > a limit of 2083 characters. > > -- > Thiago H. de Paula Figueiredo > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, > and instructor > Owner, software architect and developer, Ars Machina Tecnologia da > Informação Ltda. > http://www.arsmachina.com.br > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Re: Persisting state without HTTP Session
Em Wed, 06 Jan 2010 13:36:31 -0200, Jim O'Callaghan escreveu: Thanks for the responses Thiago. You're welcome! I'll have a look at the LinkCreationListener you suggested in your other email. Regarding the response below, does the approach not make an assumption that the objects I am trying to share between pages are persisted objects with a key(id)/value elationship? I'm using something at the moment that manages a menu stack in the user's session and some other data that is really just relevant to the user's session and not something I had thought of persisting. The approach doesn't assume your objects have an id, but it does assume you won't put much information in the URLs. Internet Explorer, for example, has a limit of 2083 characters. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
RE: Persisting state without HTTP Session
Thanks for the details Howard - I'll keep an eye on this one. Regards, Jim. -Original Message- From: Howard Lewis Ship [mailto:hls...@gmail.com] Sent: 06 January 2010 18:44 To: Tapestry users Subject: Re: Persisting state without HTTP Session Something I'm hoping to put together as either a new tapestry5 project, or as a tapx project: https://issues.apache.org/jira/browse/TAP5-53 On Wed, Jan 6, 2010 at 5:16 AM, Jim O'Callaghan wrote: > 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. > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - 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
Re: Persisting state without HTTP Session
Something I'm hoping to put together as either a new tapestry5 project, or as a tapx project: https://issues.apache.org/jira/browse/TAP5-53 On Wed, Jan 6, 2010 at 5:16 AM, Jim O'Callaghan wrote: > 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. > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
RE: Persisting state without HTTP Session
Ulrich, Lutz, Thanks for the very informative replies. Hopefully they will be useful to others also. Regards, Jim. -Original Message- From: Lutz Hühnken [mailto:lh.tapestry.l...@googlemail.com] Sent: 06 January 2010 15:56 To: Tapestry users Subject: Re: Persisting state without HTTP Session Jim, You still have some different options to pursue in a cluster.. - "sticky" sessions, so that requests of the same user will go to the same server in the cluster. Good for load balancing, but if a server fails, the users of that server will loose their session. - session replication in the cluster - this seems to be the approach you are thinking of. Here I would indeed imagine that the amount of data you store in the session heavily influences performance. - persist the session. Could be in clustered rdbms, could be one of these distributed key-value stores that are all the rage these days, like Cassandra or HBase. Maybe you could let us know what you ended up doing, once you've finished your project. Good luck, Lutz On Wed, Jan 6, 2010 at 4:37 PM, Jim O'Callaghan wrote: > Lutz, > > You raise some very interesting points. I've replied to some of the other > posters regarding the reasons I was trying to minimise session use, though > taking their replies on board and your own email I think the best course of > action is to proceed with using the session state and just minimising the > amount of data held. Thanks for your contributions. > > Regards, > Jim. -- altocon GmbH http://www.altocon.de/ Software Development, Consulting Hamburg, Germany - 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
Re: Persisting state without HTTP Session
Jim, You still have some different options to pursue in a cluster.. - "sticky" sessions, so that requests of the same user will go to the same server in the cluster. Good for load balancing, but if a server fails, the users of that server will loose their session. - session replication in the cluster - this seems to be the approach you are thinking of. Here I would indeed imagine that the amount of data you store in the session heavily influences performance. - persist the session. Could be in clustered rdbms, could be one of these distributed key-value stores that are all the rage these days, like Cassandra or HBase. Maybe you could let us know what you ended up doing, once you've finished your project. Good luck, Lutz On Wed, Jan 6, 2010 at 4:37 PM, Jim O'Callaghan wrote: > Lutz, > > You raise some very interesting points. I've replied to some of the other > posters regarding the reasons I was trying to minimise session use, though > taking their replies on board and your own email I think the best course of > action is to proceed with using the session state and just minimising the > amount of data held. Thanks for your contributions. > > Regards, > Jim. -- altocon GmbH http://www.altocon.de/ Software Development, Consulting Hamburg, Germany - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Persisting state without HTTP Session
You might want to have a look at the "Clustering Issues" section of [1]. Tapestry already has some mechanisms built-in to help you with deciding when your session attributes have changed and need to be propagated to the other cluster nodes. Of course, keeping the amount of information stored inside the session to a minimum is always a good practice. E.g. use keys instead of serialized objects, etc. Uli [1] http://tapestry.apache.org/tapestry5.1/guide/persist.html On 06.01.2010 16:36 schrieb Jim O'Callaghan: 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 - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
RE: Persisting state without HTTP Session
Lutz, You raise some very interesting points. I've replied to some of the other posters regarding the reasons I was trying to minimise session use, though taking their replies on board and your own email I think the best course of action is to proceed with using the session state and just minimising the amount of data held. Thanks for your contributions. Regards, Jim. -Original Message- From: Lutz Hühnken [mailto:lh.tapestry.l...@googlemail.com] Sent: 06 January 2010 15:26 To: Tapestry users Subject: Re: Persisting state without HTTP Session I see. There wouldn't be much handling, though, one could probably implement a "cookie" persistence strategy, so that you could use the @Persist annotation. Doesn't that even exist already? The thing you are in favor of, using post.. there'll be some disadvantages. I assume you won't be using redirect-after-post much, if you don't want to keep state on the server side. You would have to disable that, as it is the default in Tapestry. I could imagine having a central dispatcher... every post goes to that central dispatcher, the page to be rendered would be one of the parameters. The other parameters would constitute the context for that page. That would be kept track of with hidden form fields. Might be possible, but not a nice solution. No bookmarks, possibly no navigation with browser back - forward buttons.. You could write your context into a database after request processing, and read it on the next request. Of course that would be exactly the same as using a session (in fact, you can configure most servers to store the session in a database). Only slower (than in-memory sessions). Well, now we know why people came up with the session concept. It is actually quite a good approach. What was the reason again you don't want to use it? On Wed, Jan 6, 2010 at 3:04 PM, Jim O'Callaghan wrote: > Lutz, > > Thanks for the response - Cookies would be a last resort - I don't want to be > managing cookies and also feel it makes the app more breakable (fundamental > state could be broken with browser security settings). What I'm after is > something akin to PageActivationContext but that passes the relevant > object(s) using Request parameters rather than the querystring / url - thanks. > > Regards, > Jim. > > -Original Message- > From: Lutz Hühnken [mailto:lh.tapestry.l...@googlemail.com] > Sent: 06 January 2010 13:50 > To: Tapestry users > Subject: Re: Persisting state without HTTP Session > > > Cookies come to mind, would that be an option? > > > On Wed, Jan 6, 2010 at 2:16 PM, Jim O'Callaghan wrote: >> 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. >> -- altocon GmbH http://www.altocon.de/ Software Development, Consulting Hamburg, Germany - 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
RE: Persisting state without HTTP Session
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
RE: Persisting state without HTTP Session
Thanks for the responses Thiago. I'll have a look at the LinkCreationListener you suggested in your other email. Regarding the response below, does the approach not make an assumption that the objects I am trying to share between pages are persisted objects with a key(id)/value relationship? I'm using something at the moment that manages a menu stack in the user's session and some other data that is really just relevant to the user's session and not something I had thought of persisting. Your point regarding POST only working for forms and not links is relevant - I had not considered this. Regards, Jim. -Original Message- From: Thiago H. de Paula Figueiredo [mailto:thiag...@gmail.com] Sent: 06 January 2010 14:40 To: Tapestry users Subject: Re: Persisting state without HTTP Session Em Wed, 06 Jan 2010 11:16:23 -0200, Jim O'Callaghan escreveu: > Hi, 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) You don't need to serialize the objects: just add ValueEncoders to tell Tapestry how it will get the id from a given object. This way, your URL only has IDs, not whole objects. Anyway, is implementing a completely session-less application viable? In any technology? Using POST is complicated because it only works for forms, not links. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - 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
Re: Persisting state without HTTP Session
I see. There wouldn't be much handling, though, one could probably implement a "cookie" persistence strategy, so that you could use the @Persist annotation. Doesn't that even exist already? The thing you are in favor of, using post.. there'll be some disadvantages. I assume you won't be using redirect-after-post much, if you don't want to keep state on the server side. You would have to disable that, as it is the default in Tapestry. I could imagine having a central dispatcher... every post goes to that central dispatcher, the page to be rendered would be one of the parameters. The other parameters would constitute the context for that page. That would be kept track of with hidden form fields. Might be possible, but not a nice solution. No bookmarks, possibly no navigation with browser back - forward buttons.. You could write your context into a database after request processing, and read it on the next request. Of course that would be exactly the same as using a session (in fact, you can configure most servers to store the session in a database). Only slower (than in-memory sessions). Well, now we know why people came up with the session concept. It is actually quite a good approach. What was the reason again you don't want to use it? On Wed, Jan 6, 2010 at 3:04 PM, Jim O'Callaghan wrote: > Lutz, > > Thanks for the response - Cookies would be a last resort - I don't want to be > managing cookies and also feel it makes the app more breakable (fundamental > state could be broken with browser security settings). What I'm after is > something akin to PageActivationContext but that passes the relevant > object(s) using Request parameters rather than the querystring / url - thanks. > > Regards, > Jim. > > -Original Message- > From: Lutz Hühnken [mailto:lh.tapestry.l...@googlemail.com] > Sent: 06 January 2010 13:50 > To: Tapestry users > Subject: Re: Persisting state without HTTP Session > > > Cookies come to mind, would that be an option? > > > On Wed, Jan 6, 2010 at 2:16 PM, Jim O'Callaghan wrote: >> 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. >> -- altocon GmbH http://www.altocon.de/ Software Development, Consulting Hamburg, Germany - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
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
Re: Persisting state without HTTP Session
Em Wed, 06 Jan 2010 12:04:44 -0200, Jim O'Callaghan escreveu: What I'm after is something akin to PageActivationContext but that passes the relevant object(s) using Request parameters rather than the querystring / url - thanks. Take a look at the LinkCreationListener interface. You can implement one and contribute it to the LinkCreationHub service. A RequestFilter could be used to get the parameters from the query string and set the appropriate properties. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Persisting state without HTTP Session
Em Wed, 06 Jan 2010 11:16:23 -0200, Jim O'Callaghan escreveu: Hi, 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) You don't need to serialize the objects: just add ValueEncoders to tell Tapestry how it will get the id from a given object. This way, your URL only has IDs, not whole objects. Anyway, is implementing a completely session-less application viable? In any technology? Using POST is complicated because it only works for forms, not links. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
RE: Persisting state without HTTP Session
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
RE: Persisting state without HTTP Session
Lutz, Thanks for the response - Cookies would be a last resort - I don't want to be managing cookies and also feel it makes the app more breakable (fundamental state could be broken with browser security settings). What I'm after is something akin to PageActivationContext but that passes the relevant object(s) using Request parameters rather than the querystring / url - thanks. Regards, Jim. -Original Message- From: Lutz Hühnken [mailto:lh.tapestry.l...@googlemail.com] Sent: 06 January 2010 13:50 To: Tapestry users Subject: Re: Persisting state without HTTP Session Cookies come to mind, would that be an option? On Wed, Jan 6, 2010 at 2:16 PM, Jim O'Callaghan wrote: > 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. > -- altocon GmbH http://www.altocon.de/ Software Development, Consulting Hamburg, Germany - 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
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
Re: Persisting state without HTTP Session
Cookies come to mind, would that be an option? On Wed, Jan 6, 2010 at 2:16 PM, Jim O'Callaghan wrote: > 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. > -- altocon GmbH http://www.altocon.de/ Software Development, Consulting Hamburg, Germany - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Persisting state without HTTP Session
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.