T5.3: per page context session storage?

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

T5.3: per page context session storage?

Dmitriy Vsekhvalnov
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.
Reply | Threaded
Open this post in threaded view
|

Re: T5.3: per page context session storage?

Dragan Sahpaski
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 <[hidden email]
> 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.
>
Reply | Threaded
Open this post in threaded view
|

Re: T5.3: per page context session storage?

Lance Java
In reply to this post by Dmitriy Vsekhvalnov
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.
Reply | Threaded
Open this post in threaded view
|

Re: T5.3: per page context session storage?

Thiago H de Paula Figueiredo
On Wed, 06 Nov 2013 18:37:24 -0200, Lance Java <[hidden email]>  
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: T5.3: per page context session storage?

Dmitriy Vsekhvalnov
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 <
[hidden email]> wrote:

> On Wed, 06 Nov 2013 18:37:24 -0200, Lance Java <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: T5.3: per page context session storage?

Lance Java
Ah, then you need conversation scope as Dragan has suggested.... I was just
checking ;)
 On 7 Nov 2013 11:19, "Dmitriy Vsekhvalnov" <[hidden email]> 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 <
> [hidden email]> wrote:
>
> > On Wed, 06 Nov 2013 18:37:24 -0200, Lance Java <
> [hidden email]>
> > 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: T5.3: per page context session storage?

John
In reply to this post by Lance Java
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.
Reply | Threaded
Open this post in threaded view
|

Re: T5.3: per page context session storage?

Jens Breitenstein
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" <[hidden email]>:
>
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: T5.3: per page context session storage?

Thiago H de Paula Figueiredo
In reply to this post by Dmitriy Vsekhvalnov
On Thu, 07 Nov 2013 09:16:15 -0200, Dmitriy Vsekhvalnov  
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: T5.3: per page context session storage?

Dmitriy Vsekhvalnov
In reply to this post by Dragan Sahpaski
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
<[hidden email]>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 <
> [hidden email]
> > 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.
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: T5.3: per page context session storage?

Dragan Sahpaski
On Thu, Nov 7, 2013 at 2:07 PM, Dmitriy Vsekhvalnov
<[hidden email]>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
> <[hidden email]>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 <
> > [hidden email]
> > > 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.
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: T5.3: per page context session storage?

Thiago H de Paula Figueiredo
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  
<[hidden email]> wrote:

> On Thu, Nov 7, 2013 at 2:07 PM, Dmitriy Vsekhvalnov
> <[hidden email]>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
>> <[hidden email]>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 <
>> > [hidden email]
>> > > 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: T5.3: per page context session storage?

Dragan Sahpaski
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 <
[hidden email]> 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 <
> [hidden email]> wrote:
>
>  On Thu, Nov 7, 2013 at 2:07 PM, Dmitriy Vsekhvalnov
>> <[hidden email]>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
>>> <[hidden email]>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 <
>>> > [hidden email]
>>> > > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: T5.3: per page context session storage?

Dmitriy Vsekhvalnov
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
<[hidden email]>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 <
> [hidden email]> 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 <
> > [hidden email]> wrote:
> >
> >  On Thu, Nov 7, 2013 at 2:07 PM, Dmitriy Vsekhvalnov
> >> <[hidden email]>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
> >>> <[hidden email]>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 <
> >>> > [hidden email]
> >>> > > 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: T5.3: per page context session storage?

Thiago H de Paula Figueiredo
In reply to this post by Dragan Sahpaski
On Thu, 07 Nov 2013 12:16:46 -0200, Dragan Sahpaski  
<[hidden email]> 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 <
> [hidden email]> 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 <
>> [hidden email]> wrote:
>>
>>  On Thu, Nov 7, 2013 at 2:07 PM, Dmitriy Vsekhvalnov
>>> <[hidden email]>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
>>>> <[hidden email]>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 <
>>>> > [hidden email]
>>>> > > 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: T5.3: per page context session storage?

Dragan Sahpaski
In reply to this post by Dmitriy Vsekhvalnov
On Thu, Nov 7, 2013 at 3:24 PM, Dmitriy Vsekhvalnov
<[hidden email]>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
> <[hidden email]>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 <
> > [hidden email]> 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 <
> > > [hidden email]> wrote:
> > >
> > >  On Thu, Nov 7, 2013 at 2:07 PM, Dmitriy Vsekhvalnov
> > >> <[hidden email]>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
> > >>> <[hidden email]>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 <
> > >>> > [hidden email]
> > >>> > > 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: T5.3: per page context session storage?

Thiago H de Paula Figueiredo
On Thu, 07 Nov 2013 12:27:41 -0200, Dragan Sahpaski  
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: T5.3: per page context session storage?

Dragan Sahpaski
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 <
[hidden email]> wrote:

> On Thu, 07 Nov 2013 12:27:41 -0200, Dragan Sahpaski <
> [hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: T5.3: per page context session storage?

Thiago H de Paula Figueiredo
In reply to this post by Dragan Sahpaski
On Thu, 07 Nov 2013 12:27:41 -0200, Dragan Sahpaski  
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: T5.3: per page context session storage?

Kalle Korhonen-2
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 <
[hidden email]> wrote:

> On Thu, 07 Nov 2013 12:27:41 -0200, Dragan Sahpaski <
> [hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
12