I had considered implementing a query parameter earlier as instinctively, it sounds logically like the right approach. However, the nice thing about the path encoded context parameters is that you don't have to do additional work making sure that the context is carried through. Regardless, adding support for query parameter from the library's point of view is likely very inexpensive so I don't see why not.
On the use of sessions, used properly, it can greatly improve performance of the application and scalability as well depending on where the bottlenecks are. I've tried to include some of the reasoning in the documentation as well, but I strongly think that the typical live time of web conversations should be within seconds. Longer session use quickly lead to scalability issues with inefficient memory consumption. Finally, I've considered making the module more annotation-driven but given how Tapestry initializes pages, it's critical to be able to control just when the conversation is created. I'll probably make another go at this when I implement support for T5.4 (whenever we get to a public beta stage with it first). Kalle On Thu, Nov 7, 2013 at 9:04 AM, Thiago H de Paula Figueiredo < thiag...@gmail.com> wrote: > On Thu, 07 Nov 2013 12:27:41 -0200, Dragan Sahpaski < > dragan.sahpa...@gmail.com> wrote: > > I agree that query support would be very nice. You could file a JIRA for >> it http://jira.codehaus.org/browse/TYNAMO >> > > Done: https://jira.codehaus.org/browse/TYNAMO-232 > > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.com.br > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
