You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Dmitriy Vsekhvalnov <dv...@gmail.com> on 2013/11/06 12:11:43 UTC
T5.3: per page context session storage?
Hi all,
looking for a way to have session storage per context, e.g. 2 pages:
/profile/details/1
/profile/details/2
if work with both in different tabs session storage data obviously
clashing.
Any ideas how to make per-context session?
Thanks.
Re: T5.3: per page context session storage?
Posted by Lance Java <la...@googlemail.com>.
Ah, then you need conversation scope as Dragan has suggested.... I was just
checking ;)
On 7 Nov 2013 11:19, "Dmitriy Vsekhvalnov" <dv...@gmail.com> wrote:
> Well, if you don't save your object(s) in memory you should save in some
> other place, right?
>
> So, what are you doing if you have to edit object with several
> pages/screens before finally committing it?
>
>
> On Thu, Nov 7, 2013 at 2:03 AM, Thiago H de Paula Figueiredo <
> thiagohp@gmail.com> wrote:
>
> > On Wed, 06 Nov 2013 18:37:24 -0200, Lance Java <
> lance.java@googlemail.com>
> > wrote:
> >
> > Any time someone wants to use the session, I always ask why. I avoid
> >> session usage wherever possible. If there's no real need for it, I
> >> suggest you keep your app stateless and use the page activation context
> /
> >> event
> >> context to pass parameters.
> >>
> >
> > Agreed 100%. Besides the lower memory usage, it also avoids some
> problems.
> >
> > --
> > Thiago H. de Paula Figueiredo
> > Tapestry, Java and Hibernate consultant and developer
> > http://machina.com.br
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
Re: T5.3: per page context session storage?
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 07 Nov 2013 09:16:15 -0200, Dmitriy Vsekhvalnov
<dv...@gmail.com> wrote:
> Well, if you don't save your object(s) in memory you should save in some
> other place, right?
Right. Session storage is storage. :P
> So, what are you doing if you have to edit object with several
> pages/screens before finally committing it?
Then you probably cannot avoid using a session[1]. :) The point is that,
when you can avoid that, you should. ;)
[1] Unless you store the intermediates states in some temporary location
other than session.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.3: per page context session storage?
Posted by Dmitriy Vsekhvalnov <dv...@gmail.com>.
Well, if you don't save your object(s) in memory you should save in some
other place, right?
So, what are you doing if you have to edit object with several
pages/screens before finally committing it?
On Thu, Nov 7, 2013 at 2:03 AM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Wed, 06 Nov 2013 18:37:24 -0200, Lance Java <la...@googlemail.com>
> wrote:
>
> Any time someone wants to use the session, I always ask why. I avoid
>> session usage wherever possible. If there's no real need for it, I
>> suggest you keep your app stateless and use the page activation context /
>> event
>> context to pass parameters.
>>
>
> Agreed 100%. Besides the lower memory usage, it also avoids some problems.
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: T5.3: per page context session storage?
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Wed, 06 Nov 2013 18:37:24 -0200, Lance Java <la...@googlemail.com>
wrote:
> Any time someone wants to use the session, I always ask why. I avoid
> session usage wherever possible. If there's no real need for it, I
> suggest you keep your app stateless and use the page activation context
> / event
> context to pass parameters.
Agreed 100%. Besides the lower memory usage, it also avoids some problems.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.3: per page context session storage?
Posted by "mailinglist@j-b-s.de" <ma...@j-b-s.de>.
I think it strongly depends...
Overuse of session when parameters will do is as wrong as trying to avoid session at all by making the rest complicated and unmaintainable.
If you need security / permission there is no decision you can make. For writing stateful wizard like dialogs it depends on complexity of your dialog(s).
Concerning the initial question, maybe a dispatcher will do? You know the request and you can access the sessionstate. If session objects follow a page like naming scheme you can wipe objects you no longer need because the user went to a different page (hierarchy) for example.
Jens
Von meinem iPhone gesendet
> Am 07.11.2013 um 12:44 schrieb "John" <jo...@quivinco.com>:
>
> Hi,
>
> I worked on a monster of an e-commerce package called Blue Martini. Their consultants also liked to build the system where all the data was put in hidden page fields and not use the session. This burdens the network with sending data that is not required on the client and you cannot use get method because of practical limitations on request lengths. But then again you preserve server memory and retain some more server scalability. I can't recall how things were with using back buttons, of course when stat eis in the page you effectively get back to the previous state which is good, but I think there may of been other issues? I think memory is more scalable reliable and secure vs network resourcing, there is big memory. It seems to be about finding the right balance and I think technical developments and limitations favour server memory.
>
> Having said that ,I tend to just keep the bare minimum in session such as the users ID and permissions. I am using Tapestry FLASH property persistence where possible, this seems to be a good compromise.
>
> I'm interested to hear more about approaches on this topic.
>
>
> ----- Original Message -----
> From: Lance Java
> To: Tapestry users
> Sent: Wednesday, November 06, 2013 8:37 PM
> Subject: Re: T5.3: per page context session storage?
>
>
> Any time someone wants to use the session, I always ask why. I avoid
> session usage wherever possible. If there's no real need for it, I suggest
> you keep your app stateless and use the page activation context / event
> context to pass parameters.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.3: per page context session storage?
Posted by John <jo...@quivinco.com>.
Hi,
I worked on a monster of an e-commerce package called Blue Martini. Their consultants also liked to build the system where all the data was put in hidden page fields and not use the session. This burdens the network with sending data that is not required on the client and you cannot use get method because of practical limitations on request lengths. But then again you preserve server memory and retain some more server scalability. I can't recall how things were with using back buttons, of course when stat eis in the page you effectively get back to the previous state which is good, but I think there may of been other issues? I think memory is more scalable reliable and secure vs network resourcing, there is big memory. It seems to be about finding the right balance and I think technical developments and limitations favour server memory.
Having said that ,I tend to just keep the bare minimum in session such as the users ID and permissions. I am using Tapestry FLASH property persistence where possible, this seems to be a good compromise.
I'm interested to hear more about approaches on this topic.
----- Original Message -----
From: Lance Java
To: Tapestry users
Sent: Wednesday, November 06, 2013 8:37 PM
Subject: Re: T5.3: per page context session storage?
Any time someone wants to use the session, I always ask why. I avoid
session usage wherever possible. If there's no real need for it, I suggest
you keep your app stateless and use the page activation context / event
context to pass parameters.
Re: T5.3: per page context session storage?
Posted by Lance Java <la...@googlemail.com>.
Any time someone wants to use the session, I always ask why. I avoid
session usage wherever possible. If there's no real need for it, I suggest
you keep your app stateless and use the page activation context / event
context to pass parameters.
Re: T5.3: per page context session storage?
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 07 Nov 2013 12:16:46 -0200, Dragan Sahpaski
<dr...@gmail.com> wrote:
> Not out of the box.
So consider this an improvement suggestion. :)
> See
> http://grepcode.com/file/repo1.maven.org/maven2/org.tynamo/tapestry-conversations/0.1.2/org/tynamo/conversations/services/ConversationManagerImpl.java
> I would prefer using it as a query param in some cases. You could do it
> yourself by manually activating the conversation etc.
>
> Cheers,
> Dragan Sahpaski
>
>
> On Thu, Nov 7, 2013 at 3:01 PM, Thiago H de Paula Figueiredo <
> thiagohp@gmail.com> wrote:
>
>> Quick question: does the package support mapping the conversation id to
>> a
>> query parameter?
>>
>>
>> On Thu, 07 Nov 2013 11:30:59 -0200, Dragan Sahpaski <
>> dragan.sahpaski@gmail.com> wrote:
>>
>> On Thu, Nov 7, 2013 at 2:07 PM, Dmitriy Vsekhvalnov
>>> <dv...@gmail.com>wrote:
>>>
>>> Hey Dragan,
>>>>
>>>> conversations seems to be ok, except one issue i ran into, my context
>>>> looks
>>>> like this: /page/parent-id/child-id or /page/parent-id, e.g.
>>>>
>>>> /page/100/23 - edit object
>>>> /page/100 - new object
>>>>
>>>> if i add conversion id how can i distinguish second one?
>>>> /page/100/123213213 vs. /page/100/23 ?
>>>>
>>>>
>>> See org.tynamo.conversations.services.ConversationManager. You can
>>> check
>>> if the second parameter is a valid conversation id. Best to keep the
>>> conversation id as the last parameter and check for it's validity. BTW
>>> if
>>> you've already decided to use conversations consider if persisting the
>>> parent-id and child-id context parameters is a viable option. With the
>>> conversation id in the page context your pages are bookmarkable, so now
>>> the
>>> balance between keeping objects in memory or in the context is a
>>> complexity
>>> balancing issue. More complex code or bigger memory hit. Up to you to
>>> decide.
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>> On Wed, Nov 6, 2013 at 3:23 PM, Dragan Sahpaski
>>>> <dr...@gmail.com>wrote:
>>>>
>>>> > Hi Dmitriy,
>>>> > What you've described is having a conversational scope.
>>>> > Look at the tapestry-conversations module
>>>> > http://tynamo.org/tapestry-conversations+guide. I think the guide is
>>>> > pretty
>>>> > clear and you will have an easy time integrating it.
>>>> > We use the module in multiple projects and it works very well.
>>>> >
>>>> > Cheers,
>>>> > Dragan Sahpaski
>>>> >
>>>> >
>>>> > On Wed, Nov 6, 2013 at 12:11 PM, Dmitriy Vsekhvalnov <
>>>> > dvsekhvalnov@gmail.com
>>>> > > wrote:
>>>> >
>>>> > > Hi all,
>>>> > >
>>>> > > looking for a way to have session storage per context, e.g. 2
>>>> pages:
>>>> > >
>>>> > > /profile/details/1
>>>> > > /profile/details/2
>>>> > >
>>>> > > if work with both in different tabs session storage data obviously
>>>> > > clashing.
>>>> > >
>>>> > > Any ideas how to make per-context session?
>>>> > >
>>>> > > Thanks.
>>>> > >
>>>> >
>>>>
>>>>
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Tapestry, Java and Hibernate consultant and developer
>> http://machina.com.br
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.3: per page context session storage?
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 07 Nov 2013 15:24:35 -0200, Kalle Korhonen
<ka...@gmail.com> wrote:
> 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.
Why not advising annotated methods? This prevents any relation to the way
pages are initialized.
> 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).
It's not beta yet, but it's stable and works very well.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.3: per page context session storage?
Posted by Kalle Korhonen <ka...@gmail.com>.
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 <
thiagohp@gmail.com> wrote:
> On Thu, 07 Nov 2013 12:27:41 -0200, Dragan Sahpaski <
> dragan.sahpaski@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: T5.3: per page context session storage?
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 07 Nov 2013 12:27:41 -0200, Dragan Sahpaski
<dr...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.3: per page context session storage?
Posted by Dragan Sahpaski <dr...@gmail.com>.
See the sign up for a JIRA account section here
http://jira.codehaus.org/secure/Dashboard.jspa
Cheers,
Dragan Sahpaski
On Thu, Nov 7, 2013 at 3:38 PM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Thu, 07 Nov 2013 12:27:41 -0200, Dragan Sahpaski <
> dragan.sahpaski@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
>>
>
> How do I get an user there? :)
>
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: T5.3: per page context session storage?
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 07 Nov 2013 12:27:41 -0200, Dragan Sahpaski
<dr...@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
How do I get an user there? :)
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.3: per page context session storage?
Posted by Dragan Sahpaski <dr...@gmail.com>.
On Thu, Nov 7, 2013 at 3:24 PM, Dmitriy Vsekhvalnov
<dv...@gmail.com>wrote:
> Quite nice, i got it working, thanks Dragan.
>
> Any plans to extend to be more annotation drive? Like may be:
>
> @Conversational
> public void onActivate(...) {}
>
> @Conversational
> public long onPassivate(...) {}
>
> to auto manage conversation id, extract/prepend to context list?
>
> Query param support out of box can be nice as well.
>
I agree that query support would be very nice. You could file a JIRA for
it http://jira.codehaus.org/browse/TYNAMO
>
>
> On Thu, Nov 7, 2013 at 6:16 PM, Dragan Sahpaski
> <dr...@gmail.com>wrote:
>
> > Not out of the box.
> > See
> >
> >
> http://grepcode.com/file/repo1.maven.org/maven2/org.tynamo/tapestry-conversations/0.1.2/org/tynamo/conversations/services/ConversationManagerImpl.java
> > I would prefer using it as a query param in some cases. You could do it
> > yourself by manually activating the conversation etc.
> >
> > Cheers,
> > Dragan Sahpaski
> >
> >
> > On Thu, Nov 7, 2013 at 3:01 PM, Thiago H de Paula Figueiredo <
> > thiagohp@gmail.com> wrote:
> >
> > > Quick question: does the package support mapping the conversation id
> to a
> > > query parameter?
> > >
> > >
> > > On Thu, 07 Nov 2013 11:30:59 -0200, Dragan Sahpaski <
> > > dragan.sahpaski@gmail.com> wrote:
> > >
> > > On Thu, Nov 7, 2013 at 2:07 PM, Dmitriy Vsekhvalnov
> > >> <dv...@gmail.com>wrote:
> > >>
> > >> Hey Dragan,
> > >>>
> > >>> conversations seems to be ok, except one issue i ran into, my context
> > >>> looks
> > >>> like this: /page/parent-id/child-id or /page/parent-id, e.g.
> > >>>
> > >>> /page/100/23 - edit object
> > >>> /page/100 - new object
> > >>>
> > >>> if i add conversion id how can i distinguish second one?
> > >>> /page/100/123213213 vs. /page/100/23 ?
> > >>>
> > >>>
> > >> See org.tynamo.conversations.services.ConversationManager. You can
> > check
> > >> if the second parameter is a valid conversation id. Best to keep the
> > >> conversation id as the last parameter and check for it's validity. BTW
> > if
> > >> you've already decided to use conversations consider if persisting the
> > >> parent-id and child-id context parameters is a viable option. With the
> > >> conversation id in the page context your pages are bookmarkable, so
> now
> > >> the
> > >> balance between keeping objects in memory or in the context is a
> > >> complexity
> > >> balancing issue. More complex code or bigger memory hit. Up to you to
> > >> decide.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>>
> > >>>
> > >>>
> > >>> On Wed, Nov 6, 2013 at 3:23 PM, Dragan Sahpaski
> > >>> <dr...@gmail.com>wrote:
> > >>>
> > >>> > Hi Dmitriy,
> > >>> > What you've described is having a conversational scope.
> > >>> > Look at the tapestry-conversations module
> > >>> > http://tynamo.org/tapestry-conversations+guide. I think the guide
> is
> > >>> > pretty
> > >>> > clear and you will have an easy time integrating it.
> > >>> > We use the module in multiple projects and it works very well.
> > >>> >
> > >>> > Cheers,
> > >>> > Dragan Sahpaski
> > >>> >
> > >>> >
> > >>> > On Wed, Nov 6, 2013 at 12:11 PM, Dmitriy Vsekhvalnov <
> > >>> > dvsekhvalnov@gmail.com
> > >>> > > wrote:
> > >>> >
> > >>> > > Hi all,
> > >>> > >
> > >>> > > looking for a way to have session storage per context, e.g. 2
> > pages:
> > >>> > >
> > >>> > > /profile/details/1
> > >>> > > /profile/details/2
> > >>> > >
> > >>> > > if work with both in different tabs session storage data
> obviously
> > >>> > > clashing.
> > >>> > >
> > >>> > > Any ideas how to make per-context session?
> > >>> > >
> > >>> > > Thanks.
> > >>> > >
> > >>> >
> > >>>
> > >>>
> > >
> > > --
> > > Thiago H. de Paula Figueiredo
> > > Tapestry, Java and Hibernate consultant and developer
> > > http://machina.com.br
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> >
>
Re: T5.3: per page context session storage?
Posted by Dmitriy Vsekhvalnov <dv...@gmail.com>.
Quite nice, i got it working, thanks Dragan.
Any plans to extend to be more annotation drive? Like may be:
@Conversational
public void onActivate(...) {}
@Conversational
public long onPassivate(...) {}
to auto manage conversation id, extract/prepend to context list?
Query param support out of box can be nice as well.
On Thu, Nov 7, 2013 at 6:16 PM, Dragan Sahpaski
<dr...@gmail.com>wrote:
> Not out of the box.
> See
>
> http://grepcode.com/file/repo1.maven.org/maven2/org.tynamo/tapestry-conversations/0.1.2/org/tynamo/conversations/services/ConversationManagerImpl.java
> I would prefer using it as a query param in some cases. You could do it
> yourself by manually activating the conversation etc.
>
> Cheers,
> Dragan Sahpaski
>
>
> On Thu, Nov 7, 2013 at 3:01 PM, Thiago H de Paula Figueiredo <
> thiagohp@gmail.com> wrote:
>
> > Quick question: does the package support mapping the conversation id to a
> > query parameter?
> >
> >
> > On Thu, 07 Nov 2013 11:30:59 -0200, Dragan Sahpaski <
> > dragan.sahpaski@gmail.com> wrote:
> >
> > On Thu, Nov 7, 2013 at 2:07 PM, Dmitriy Vsekhvalnov
> >> <dv...@gmail.com>wrote:
> >>
> >> Hey Dragan,
> >>>
> >>> conversations seems to be ok, except one issue i ran into, my context
> >>> looks
> >>> like this: /page/parent-id/child-id or /page/parent-id, e.g.
> >>>
> >>> /page/100/23 - edit object
> >>> /page/100 - new object
> >>>
> >>> if i add conversion id how can i distinguish second one?
> >>> /page/100/123213213 vs. /page/100/23 ?
> >>>
> >>>
> >> See org.tynamo.conversations.services.ConversationManager. You can
> check
> >> if the second parameter is a valid conversation id. Best to keep the
> >> conversation id as the last parameter and check for it's validity. BTW
> if
> >> you've already decided to use conversations consider if persisting the
> >> parent-id and child-id context parameters is a viable option. With the
> >> conversation id in the page context your pages are bookmarkable, so now
> >> the
> >> balance between keeping objects in memory or in the context is a
> >> complexity
> >> balancing issue. More complex code or bigger memory hit. Up to you to
> >> decide.
> >>
> >>
> >>
> >>
> >>
> >>>
> >>>
> >>>
> >>> On Wed, Nov 6, 2013 at 3:23 PM, Dragan Sahpaski
> >>> <dr...@gmail.com>wrote:
> >>>
> >>> > Hi Dmitriy,
> >>> > What you've described is having a conversational scope.
> >>> > Look at the tapestry-conversations module
> >>> > http://tynamo.org/tapestry-conversations+guide. I think the guide is
> >>> > pretty
> >>> > clear and you will have an easy time integrating it.
> >>> > We use the module in multiple projects and it works very well.
> >>> >
> >>> > Cheers,
> >>> > Dragan Sahpaski
> >>> >
> >>> >
> >>> > On Wed, Nov 6, 2013 at 12:11 PM, Dmitriy Vsekhvalnov <
> >>> > dvsekhvalnov@gmail.com
> >>> > > wrote:
> >>> >
> >>> > > Hi all,
> >>> > >
> >>> > > looking for a way to have session storage per context, e.g. 2
> pages:
> >>> > >
> >>> > > /profile/details/1
> >>> > > /profile/details/2
> >>> > >
> >>> > > if work with both in different tabs session storage data obviously
> >>> > > clashing.
> >>> > >
> >>> > > Any ideas how to make per-context session?
> >>> > >
> >>> > > Thanks.
> >>> > >
> >>> >
> >>>
> >>>
> >
> > --
> > Thiago H. de Paula Figueiredo
> > Tapestry, Java and Hibernate consultant and developer
> > http://machina.com.br
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
Re: T5.3: per page context session storage?
Posted by Dragan Sahpaski <dr...@gmail.com>.
Not out of the box.
See
http://grepcode.com/file/repo1.maven.org/maven2/org.tynamo/tapestry-conversations/0.1.2/org/tynamo/conversations/services/ConversationManagerImpl.java
I would prefer using it as a query param in some cases. You could do it
yourself by manually activating the conversation etc.
Cheers,
Dragan Sahpaski
On Thu, Nov 7, 2013 at 3:01 PM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> Quick question: does the package support mapping the conversation id to a
> query parameter?
>
>
> On Thu, 07 Nov 2013 11:30:59 -0200, Dragan Sahpaski <
> dragan.sahpaski@gmail.com> wrote:
>
> On Thu, Nov 7, 2013 at 2:07 PM, Dmitriy Vsekhvalnov
>> <dv...@gmail.com>wrote:
>>
>> Hey Dragan,
>>>
>>> conversations seems to be ok, except one issue i ran into, my context
>>> looks
>>> like this: /page/parent-id/child-id or /page/parent-id, e.g.
>>>
>>> /page/100/23 - edit object
>>> /page/100 - new object
>>>
>>> if i add conversion id how can i distinguish second one?
>>> /page/100/123213213 vs. /page/100/23 ?
>>>
>>>
>> See org.tynamo.conversations.services.ConversationManager. You can check
>> if the second parameter is a valid conversation id. Best to keep the
>> conversation id as the last parameter and check for it's validity. BTW if
>> you've already decided to use conversations consider if persisting the
>> parent-id and child-id context parameters is a viable option. With the
>> conversation id in the page context your pages are bookmarkable, so now
>> the
>> balance between keeping objects in memory or in the context is a
>> complexity
>> balancing issue. More complex code or bigger memory hit. Up to you to
>> decide.
>>
>>
>>
>>
>>
>>>
>>>
>>>
>>> On Wed, Nov 6, 2013 at 3:23 PM, Dragan Sahpaski
>>> <dr...@gmail.com>wrote:
>>>
>>> > Hi Dmitriy,
>>> > What you've described is having a conversational scope.
>>> > Look at the tapestry-conversations module
>>> > http://tynamo.org/tapestry-conversations+guide. I think the guide is
>>> > pretty
>>> > clear and you will have an easy time integrating it.
>>> > We use the module in multiple projects and it works very well.
>>> >
>>> > Cheers,
>>> > Dragan Sahpaski
>>> >
>>> >
>>> > On Wed, Nov 6, 2013 at 12:11 PM, Dmitriy Vsekhvalnov <
>>> > dvsekhvalnov@gmail.com
>>> > > wrote:
>>> >
>>> > > Hi all,
>>> > >
>>> > > looking for a way to have session storage per context, e.g. 2 pages:
>>> > >
>>> > > /profile/details/1
>>> > > /profile/details/2
>>> > >
>>> > > if work with both in different tabs session storage data obviously
>>> > > clashing.
>>> > >
>>> > > Any ideas how to make per-context session?
>>> > >
>>> > > Thanks.
>>> > >
>>> >
>>>
>>>
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: T5.3: per page context session storage?
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
Quick question: does the package support mapping the conversation id to a
query parameter?
On Thu, 07 Nov 2013 11:30:59 -0200, Dragan Sahpaski
<dr...@gmail.com> wrote:
> On Thu, Nov 7, 2013 at 2:07 PM, Dmitriy Vsekhvalnov
> <dv...@gmail.com>wrote:
>
>> Hey Dragan,
>>
>> conversations seems to be ok, except one issue i ran into, my context
>> looks
>> like this: /page/parent-id/child-id or /page/parent-id, e.g.
>>
>> /page/100/23 - edit object
>> /page/100 - new object
>>
>> if i add conversion id how can i distinguish second one?
>> /page/100/123213213 vs. /page/100/23 ?
>>
>
> See org.tynamo.conversations.services.ConversationManager. You can check
> if the second parameter is a valid conversation id. Best to keep the
> conversation id as the last parameter and check for it's validity. BTW if
> you've already decided to use conversations consider if persisting the
> parent-id and child-id context parameters is a viable option. With the
> conversation id in the page context your pages are bookmarkable, so now
> the
> balance between keeping objects in memory or in the context is a
> complexity
> balancing issue. More complex code or bigger memory hit. Up to you to
> decide.
>
>
>
>
>>
>>
>>
>>
>> On Wed, Nov 6, 2013 at 3:23 PM, Dragan Sahpaski
>> <dr...@gmail.com>wrote:
>>
>> > Hi Dmitriy,
>> > What you've described is having a conversational scope.
>> > Look at the tapestry-conversations module
>> > http://tynamo.org/tapestry-conversations+guide. I think the guide is
>> > pretty
>> > clear and you will have an easy time integrating it.
>> > We use the module in multiple projects and it works very well.
>> >
>> > Cheers,
>> > Dragan Sahpaski
>> >
>> >
>> > On Wed, Nov 6, 2013 at 12:11 PM, Dmitriy Vsekhvalnov <
>> > dvsekhvalnov@gmail.com
>> > > wrote:
>> >
>> > > Hi all,
>> > >
>> > > looking for a way to have session storage per context, e.g. 2 pages:
>> > >
>> > > /profile/details/1
>> > > /profile/details/2
>> > >
>> > > if work with both in different tabs session storage data obviously
>> > > clashing.
>> > >
>> > > Any ideas how to make per-context session?
>> > >
>> > > Thanks.
>> > >
>> >
>>
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.3: per page context session storage?
Posted by Dragan Sahpaski <dr...@gmail.com>.
On Thu, Nov 7, 2013 at 2:07 PM, Dmitriy Vsekhvalnov
<dv...@gmail.com>wrote:
> Hey Dragan,
>
> conversations seems to be ok, except one issue i ran into, my context looks
> like this: /page/parent-id/child-id or /page/parent-id, e.g.
>
> /page/100/23 - edit object
> /page/100 - new object
>
> if i add conversion id how can i distinguish second one?
> /page/100/123213213 vs. /page/100/23 ?
>
See org.tynamo.conversations.services.ConversationManager. You can check
if the second parameter is a valid conversation id. Best to keep the
conversation id as the last parameter and check for it's validity. BTW if
you've already decided to use conversations consider if persisting the
parent-id and child-id context parameters is a viable option. With the
conversation id in the page context your pages are bookmarkable, so now the
balance between keeping objects in memory or in the context is a complexity
balancing issue. More complex code or bigger memory hit. Up to you to
decide.
>
>
>
>
> On Wed, Nov 6, 2013 at 3:23 PM, Dragan Sahpaski
> <dr...@gmail.com>wrote:
>
> > Hi Dmitriy,
> > What you've described is having a conversational scope.
> > Look at the tapestry-conversations module
> > http://tynamo.org/tapestry-conversations+guide. I think the guide is
> > pretty
> > clear and you will have an easy time integrating it.
> > We use the module in multiple projects and it works very well.
> >
> > Cheers,
> > Dragan Sahpaski
> >
> >
> > On Wed, Nov 6, 2013 at 12:11 PM, Dmitriy Vsekhvalnov <
> > dvsekhvalnov@gmail.com
> > > wrote:
> >
> > > Hi all,
> > >
> > > looking for a way to have session storage per context, e.g. 2 pages:
> > >
> > > /profile/details/1
> > > /profile/details/2
> > >
> > > if work with both in different tabs session storage data obviously
> > > clashing.
> > >
> > > Any ideas how to make per-context session?
> > >
> > > Thanks.
> > >
> >
>
Re: T5.3: per page context session storage?
Posted by Dmitriy Vsekhvalnov <dv...@gmail.com>.
Hey Dragan,
conversations seems to be ok, except one issue i ran into, my context looks
like this: /page/parent-id/child-id or /page/parent-id, e.g.
/page/100/23 - edit object
/page/100 - new object
if i add conversion id how can i distinguish second one?
/page/100/123213213 vs. /page/100/23 ?
On Wed, Nov 6, 2013 at 3:23 PM, Dragan Sahpaski
<dr...@gmail.com>wrote:
> Hi Dmitriy,
> What you've described is having a conversational scope.
> Look at the tapestry-conversations module
> http://tynamo.org/tapestry-conversations+guide. I think the guide is
> pretty
> clear and you will have an easy time integrating it.
> We use the module in multiple projects and it works very well.
>
> Cheers,
> Dragan Sahpaski
>
>
> On Wed, Nov 6, 2013 at 12:11 PM, Dmitriy Vsekhvalnov <
> dvsekhvalnov@gmail.com
> > wrote:
>
> > Hi all,
> >
> > looking for a way to have session storage per context, e.g. 2 pages:
> >
> > /profile/details/1
> > /profile/details/2
> >
> > if work with both in different tabs session storage data obviously
> > clashing.
> >
> > Any ideas how to make per-context session?
> >
> > Thanks.
> >
>
Re: T5.3: per page context session storage?
Posted by Dragan Sahpaski <dr...@gmail.com>.
Hi Dmitriy,
What you've described is having a conversational scope.
Look at the tapestry-conversations module
http://tynamo.org/tapestry-conversations+guide. I think the guide is pretty
clear and you will have an easy time integrating it.
We use the module in multiple projects and it works very well.
Cheers,
Dragan Sahpaski
On Wed, Nov 6, 2013 at 12:11 PM, Dmitriy Vsekhvalnov <dvsekhvalnov@gmail.com
> wrote:
> Hi all,
>
> looking for a way to have session storage per context, e.g. 2 pages:
>
> /profile/details/1
> /profile/details/2
>
> if work with both in different tabs session storage data obviously
> clashing.
>
> Any ideas how to make per-context session?
>
> Thanks.
>