headers
Buck O Five | 30 Jan 10:11
Picon

Re: Notifications when a t5 conversation has ended?

Hi thanks for the quick response!!!
 
I think I follow what you are saying.  I looked around ar some other libs to see if this is unusual and found that server side notifications of conversations ending are common, so if you dont mind I'd like to propose another solution utilizing some tapestry magic.  Which I dont think would be to much work.
 
How about using Tapestries ComponentResource.triggerEvent()? 
 
so somewhere in the Tynamo conversation code you could call:
    resources.triggerEvent( "ConversationIdle", theCachedObject );
 
then in a page that cares about the conversations expiring Tapestry would automagically call the correct event handler like so:
 
public void onConversationIdle( SomeObject myObject )
{
 ...
}
 
This would be very slick!  Or maybe I've had too much caffeine and I'm over simplifing.  Thoughts or suggestions?
 


 
On Sat, Jan 30, 2010 at 12:32 AM, Kalle Korhonen <kalle.o.korhonen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
And while I'm at it, just to answer your question if there's a better
approach for it - the answer is it depends. If the form has just a few
fields and you don't have to be overall concerned about system
resources, I'd just set a hard limit, like you expect the form to be
sent in 5 minutes after upload is complete, after which you'd delete
the files. If you want the usability to be as good as it can be, then
no, unfortunately I don't think there's any other way that would be
considerably simpler than this.

Kalle


On Sat, Jan 30, 2010 at 12:23 AM, Kalle Korhonen
<kalle.o.korhonen <at> gmail.com> wrote:
> On Fri, Jan 29, 2010 at 11:37 PM, Buck O Five <buckofive-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> I'm not sure if this is the best approach so I'll just tell you what I'm
>> trying to do and why I would want a notification that a conversation has
>> ended.
>
> ConversationModerator component is used for notifying the client of
> conversation status. But I think your case is the opposite, it seems
> you want the notifications on the server side.
>
>> There are several case in my application where uploading a file or files is
>> accompanied by a bean editor form, the catch is, file uploading is handled
>> by swfUpload which is not associated with the form at all.  Meaning the
>> files are uploaded in a separate post, which means I have to have the user
>> first submit the form so I can get the id of the new entity and then allow
>> file uploads via swfupload.   So I was thinking maybe conversations is a
>> cleaner way to fix this clunky requirement so the user could upload files
>> before the form is submitted.   The catch here would be deleting any
>> uploaded files (from disk) when a conversation has expired.  Is there a way
>> to do this, or maybe there is a better approach? Thanks for your time and
>> all your hard work with the new tynamo project.  It looks very promising!
>
> Yes, from usability perspective you'd probably like to let your users
> start uploading the files right away, after which they can focus on
> filling in the other details on the form. There's a undocumented
> ConversationAware interface that can be used to invoke server-side
> actions on idle check when conversation's still active. If I get your
> requirement right, you want to delete the files in case the user had
> become idle (for which the rudimentary solutions is simple - you
> decide to delete after x mins if you haven't gotten the form back),
> but to make it user friendly, you don't want to set a hard limit but
> let the user work on the form *if* he's still there, right? Your use
> case is a bit complex for web environment, but together with
> ConversationModerator and ConversationAware you should be able to get
> this done. Basically, you'd use the ConversationModerator component
> and set its keepAlive to true, then let your page implement
> ConversationAware to reset your server side idle (which should be a
> bit longer than maxIdleSeconds you set for the conversation). Use
> Firebug to see how the requests behave and obviously you need to
> implement the watchdog thread for deleting the expired
> files-in-process yourself.
>
> Good luck and thanks for the compliments!
>
> Kalle
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Permalink | Reply |
headers
Kalle Korhonen | 30 Jan 20:18
Picon

Re: Notifications when a t5 conversation has ended?

On Sat, Jan 30, 2010 at 1:11 AM, Buck O Five <buckofive@...> wrote:
> I think I follow what you are saying.  I looked around ar some other libs to
> see if this is unusual and found that server side notifications of
> conversations ending are common, so if you dont mind I'd like to propose
> another solution utilizing some tapestry magic.  Which I dont think would be
> to much work.
> How about using Tapestries ComponentResource.triggerEvent()?
> so somewhere in the Tynamo conversation code you could call:
>     resources.triggerEvent( "ConversationIdle", theCachedObject );
> then in a page that cares about the conversations expiring Tapestry would
> automagically call the correct event handler like so:
> This would be very slick!  Or maybe I've had too much caffeine and I'm over
> simplifing.  Thoughts or suggestions?

As opposed to enhancing ConversationAware interface? triggerEvent
would be more in line with Tapestry's standard event mechanism but
unfortunately, you might be oversimplifying a bit. Certainly I didn't
mean to imply that conversation end notifications are uncommon just
that I hadn't found much use for it especially in these page-centric
conversations (since typically the page decides when to end the
conversation rather than getting notified of it). Anyway, the flaw is
that a service couldn't be using ComponentResources since that would
defeat the purpose of page pooling. If it was the page itself that
would know to triggerEvent, you could just as well handle deleting the
abandoned resources (files) right there instead of doing anything more
complicated. So no, I think this event notification mechanism needs to
be interface-based and that reminds me that I had originally planned
to use ConversationAware for sending notifications to interested
services but left it half-way. Obviously ConversationAware would need
some handle/id for the conversation (pagename, session id and
conversation id?) to be any useful for outside services. But if you'd
get the notifications this way, at least your file upload service
wouldn't need to implement the logic itself for deciding when the
uploaded files become abandoned. I'm open to enhancing the
conversations interfaces as needed, but I think you need to experiment
with the conversations a bit more to see what kind of interface would
work best for you - then let me know and/or open issues so we can get
it implemented.

Kalle

> On Sat, Jan 30, 2010 at 12:32 AM, Kalle Korhonen
> <kalle.o.korhonen@...> wrote:
>>
>> And while I'm at it, just to answer your question if there's a better
>> approach for it - the answer is it depends. If the form has just a few
>> fields and you don't have to be overall concerned about system
>> resources, I'd just set a hard limit, like you expect the form to be
>> sent in 5 minutes after upload is complete, after which you'd delete
>> the files. If you want the usability to be as good as it can be, then
>> no, unfortunately I don't think there's any other way that would be
>> considerably simpler than this.
>>
>> Kalle
>>
>>
>> On Sat, Jan 30, 2010 at 12:23 AM, Kalle Korhonen
>> <kalle.o.korhonen@...> wrote:
>> > On Fri, Jan 29, 2010 at 11:37 PM, Buck O Five <buckofive@...>
>> > wrote:
>> >> I'm not sure if this is the best approach so I'll just tell you what
>> >> I'm
>> >> trying to do and why I would want a notification that a conversation
>> >> has
>> >> ended.
>> >
>> > ConversationModerator component is used for notifying the client of
>> > conversation status. But I think your case is the opposite, it seems
>> > you want the notifications on the server side.
>> >
>> >> There are several case in my application where uploading a file or
>> >> files is
>> >> accompanied by a bean editor form, the catch is, file uploading is
>> >> handled
>> >> by swfUpload which is not associated with the form at all.  Meaning the
>> >> files are uploaded in a separate post, which means I have to have the
>> >> user
>> >> first submit the form so I can get the id of the new entity and then
>> >> allow
>> >> file uploads via swfupload.   So I was thinking maybe conversations is
>> >> a
>> >> cleaner way to fix this clunky requirement so the user could upload
>> >> files
>> >> before the form is submitted.   The catch here would be deleting any
>> >> uploaded files (from disk) when a conversation has expired.  Is there a
>> >> way
>> >> to do this, or maybe there is a better approach? Thanks for your time
>> >> and
>> >> all your hard work with the new tynamo project.  It looks very
>> >> promising!
>> >
>> > Yes, from usability perspective you'd probably like to let your users
>> > start uploading the files right away, after which they can focus on
>> > filling in the other details on the form. There's a undocumented
>> > ConversationAware interface that can be used to invoke server-side
>> > actions on idle check when conversation's still active. If I get your
>> > requirement right, you want to delete the files in case the user had
>> > become idle (for which the rudimentary solutions is simple - you
>> > decide to delete after x mins if you haven't gotten the form back),
>> > but to make it user friendly, you don't want to set a hard limit but
>> > let the user work on the form *if* he's still there, right? Your use
>> > case is a bit complex for web environment, but together with
>> > ConversationModerator and ConversationAware you should be able to get
>> > this done. Basically, you'd use the ConversationModerator component
>> > and set its keepAlive to true, then let your page implement
>> > ConversationAware to reset your server side idle (which should be a
>> > bit longer than maxIdleSeconds you set for the conversation). Use
>> > Firebug to see how the requests behave and obviously you need to
>> > implement the watchdog thread for deleting the expired
>> > files-in-process yourself.
>> >
>> > Good luck and thanks for the compliments!
>> >
>> > Kalle
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>
Permalink | Reply |
headers
Buck O Five | 1 Feb 05:39
Picon

Re: Notifications when a t5 conversation has ended?

Yeah I think your right, an interface would be better than triggering an event with the page.  An interface would provide a "global" way to manage all instead of a page by page way.  I'll play around with the conversations though.  Is the work you started in the source repository?  I wouldn't mind looking at it or even doing some of the work (I'm going to have to create a mechanism for this regardless so I might as well contribute it).

thanks again for your quick replies and suggestions to my current task.


On Sat, Jan 30, 2010 at 11:18 AM, Kalle Korhonen <kalle.o.korhonen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On Sat, Jan 30, 2010 at 1:11 AM, Buck O Five <buckofive-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I think I follow what you are saying.  I looked around ar some other libs to
> see if this is unusual and found that server side notifications of
> conversations ending are common, so if you dont mind I'd like to propose
> another solution utilizing some tapestry magic.  Which I dont think would be
> to much work.
> How about using Tapestries ComponentResource.triggerEvent()?
> so somewhere in the Tynamo conversation code you could call:
>     resources.triggerEvent( "ConversationIdle", theCachedObject );
> then in a page that cares about the conversations expiring Tapestry would
> automagically call the correct event handler like so:
> This would be very slick!  Or maybe I've had too much caffeine and I'm over
> simplifing.  Thoughts or suggestions?

As opposed to enhancing ConversationAware interface? triggerEvent
would be more in line with Tapestry's standard event mechanism but
unfortunately, you might be oversimplifying a bit. Certainly I didn't
mean to imply that conversation end notifications are uncommon just
that I hadn't found much use for it especially in these page-centric
conversations (since typically the page decides when to end the
conversation rather than getting notified of it). Anyway, the flaw is
that a service couldn't be using ComponentResources since that would
defeat the purpose of page pooling. If it was the page itself that
would know to triggerEvent, you could just as well handle deleting the
abandoned resources (files) right there instead of doing anything more
complicated. So no, I think this event notification mechanism needs to
be interface-based and that reminds me that I had originally planned
to use ConversationAware for sending notifications to interested
services but left it half-way. Obviously ConversationAware would need
some handle/id for the conversation (pagename, session id and
conversation id?) to be any useful for outside services. But if you'd
get the notifications this way, at least your file upload service
wouldn't need to implement the logic itself for deciding when the
uploaded files become abandoned. I'm open to enhancing the
conversations interfaces as needed, but I think you need to experiment
with the conversations a bit more to see what kind of interface would
work best for you - then let me know and/or open issues so we can get
it implemented.

Kalle


> On Sat, Jan 30, 2010 at 12:32 AM, Kalle Korhonen
> <kalle.o.korhonen <at> gmail.com> wrote:
>>
>> And while I'm at it, just to answer your question if there's a better
>> approach for it - the answer is it depends. If the form has just a few
>> fields and you don't have to be overall concerned about system
>> resources, I'd just set a hard limit, like you expect the form to be
>> sent in 5 minutes after upload is complete, after which you'd delete
>> the files. If you want the usability to be as good as it can be, then
>> no, unfortunately I don't think there's any other way that would be
>> considerably simpler than this.
>>
>> Kalle
>>
>>
>> On Sat, Jan 30, 2010 at 12:23 AM, Kalle Korhonen
>> <kalle.o.korhonen <at> gmail.com> wrote:
>> > On Fri, Jan 29, 2010 at 11:37 PM, Buck O Five <buckofive-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> > wrote:
>> >> I'm not sure if this is the best approach so I'll just tell you what
>> >> I'm
>> >> trying to do and why I would want a notification that a conversation
>> >> has
>> >> ended.
>> >
>> > ConversationModerator component is used for notifying the client of
>> > conversation status. But I think your case is the opposite, it seems
>> > you want the notifications on the server side.
>> >
>> >> There are several case in my application where uploading a file or
>> >> files is
>> >> accompanied by a bean editor form, the catch is, file uploading is
>> >> handled
>> >> by swfUpload which is not associated with the form at all.  Meaning the
>> >> files are uploaded in a separate post, which means I have to have the
>> >> user
>> >> first submit the form so I can get the id of the new entity and then
>> >> allow
>> >> file uploads via swfupload.   So I was thinking maybe conversations is
>> >> a
>> >> cleaner way to fix this clunky requirement so the user could upload
>> >> files
>> >> before the form is submitted.   The catch here would be deleting any
>> >> uploaded files (from disk) when a conversation has expired.  Is there a
>> >> way
>> >> to do this, or maybe there is a better approach? Thanks for your time
>> >> and
>> >> all your hard work with the new tynamo project.  It looks very
>> >> promising!
>> >
>> > Yes, from usability perspective you'd probably like to let your users
>> > start uploading the files right away, after which they can focus on
>> > filling in the other details on the form. There's a undocumented
>> > ConversationAware interface that can be used to invoke server-side
>> > actions on idle check when conversation's still active. If I get your
>> > requirement right, you want to delete the files in case the user had
>> > become idle (for which the rudimentary solutions is simple - you
>> > decide to delete after x mins if you haven't gotten the form back),
>> > but to make it user friendly, you don't want to set a hard limit but
>> > let the user work on the form *if* he's still there, right? Your use
>> > case is a bit complex for web environment, but together with
>> > ConversationModerator and ConversationAware you should be able to get
>> > this done. Basically, you'd use the ConversationModerator component
>> > and set its keepAlive to true, then let your page implement
>> > ConversationAware to reset your server side idle (which should be a
>> > bit longer than maxIdleSeconds you set for the conversation). Use
>> > Firebug to see how the requests behave and obviously you need to
>> > implement the watchdog thread for deleting the expired
>> > files-in-process yourself.
>> >
>> > Good luck and thanks for the compliments!
>> >
>> > Kalle
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Permalink | Reply |
headers
Kalle Korhonen | 1 Feb 06:56
Picon

Re: Notifications when a t5 conversation has ended?

On Sun, Jan 31, 2010 at 8:39 PM, Buck O Five <buckofive@...> wrote:
> Yeah I think your right, an interface would be better than triggering an
> event with the page.  An interface would provide a "global" way to manage
> all instead of a page by page way.  I'll play around with the conversations
> though.  Is the work you started in the source repository?  I wouldn't mind

ConversationAware? It's implemented even in the current released
version, just undocumented in the guide (referred to in the javadoc
without any actual documentation:
http://tynamo.org/constant/tapestry-conversations/apidocs/index.html).

> looking at it or even doing some of the work (I'm going to have to create a
> mechanism for this regardless so I might as well contribute it).

Currently ConversationAware is only used by ConversationModerator
component (it notifies the component's container if it's
ConversationAware, i.e:
if (componentResources.getContainer() instanceof ConversationAware)
((ConversationAware) componentResources.getContainer()).onIdleCheck();

So yea, I think the simplest path would be to enhance
ConversationAware and set up a proper listener pattern for it, called
from ConversationManager (service).  Feel free to take a look at our
svn trunk. Patches are great but not mandatory for this. I understand
fairly well your requirement and agree it could be a useful
enhancement, so I could hack up something together fairly quickly.

Kalle

> thanks again for your quick replies and suggestions to my current task.
>
>
> On Sat, Jan 30, 2010 at 11:18 AM, Kalle Korhonen
> <kalle.o.korhonen@...> wrote:
>>
>> On Sat, Jan 30, 2010 at 1:11 AM, Buck O Five <buckofive@...> wrote:
>> > I think I follow what you are saying.  I looked around ar some other
>> > libs to
>> > see if this is unusual and found that server side notifications of
>> > conversations ending are common, so if you dont mind I'd like to propose
>> > another solution utilizing some tapestry magic.  Which I dont think
>> > would be
>> > to much work.
>> > How about using Tapestries ComponentResource.triggerEvent()?
>> > so somewhere in the Tynamo conversation code you could call:
>> >     resources.triggerEvent( "ConversationIdle", theCachedObject );
>> > then in a page that cares about the conversations expiring Tapestry
>> > would
>> > automagically call the correct event handler like so:
>> > This would be very slick!  Or maybe I've had too much caffeine and I'm
>> > over
>> > simplifing.  Thoughts or suggestions?
>>
>> As opposed to enhancing ConversationAware interface? triggerEvent
>> would be more in line with Tapestry's standard event mechanism but
>> unfortunately, you might be oversimplifying a bit. Certainly I didn't
>> mean to imply that conversation end notifications are uncommon just
>> that I hadn't found much use for it especially in these page-centric
>> conversations (since typically the page decides when to end the
>> conversation rather than getting notified of it). Anyway, the flaw is
>> that a service couldn't be using ComponentResources since that would
>> defeat the purpose of page pooling. If it was the page itself that
>> would know to triggerEvent, you could just as well handle deleting the
>> abandoned resources (files) right there instead of doing anything more
>> complicated. So no, I think this event notification mechanism needs to
>> be interface-based and that reminds me that I had originally planned
>> to use ConversationAware for sending notifications to interested
>> services but left it half-way. Obviously ConversationAware would need
>> some handle/id for the conversation (pagename, session id and
>> conversation id?) to be any useful for outside services. But if you'd
>> get the notifications this way, at least your file upload service
>> wouldn't need to implement the logic itself for deciding when the
>> uploaded files become abandoned. I'm open to enhancing the
>> conversations interfaces as needed, but I think you need to experiment
>> with the conversations a bit more to see what kind of interface would
>> work best for you - then let me know and/or open issues so we can get
>> it implemented.
>>
>> Kalle
>>
>>
>> > On Sat, Jan 30, 2010 at 12:32 AM, Kalle Korhonen
>> > <kalle.o.korhonen@...> wrote:
>> >>
>> >> And while I'm at it, just to answer your question if there's a better
>> >> approach for it - the answer is it depends. If the form has just a few
>> >> fields and you don't have to be overall concerned about system
>> >> resources, I'd just set a hard limit, like you expect the form to be
>> >> sent in 5 minutes after upload is complete, after which you'd delete
>> >> the files. If you want the usability to be as good as it can be, then
>> >> no, unfortunately I don't think there's any other way that would be
>> >> considerably simpler than this.
>> >>
>> >> Kalle
>> >>
>> >>
>> >> On Sat, Jan 30, 2010 at 12:23 AM, Kalle Korhonen
>> >> <kalle.o.korhonen@...> wrote:
>> >> > On Fri, Jan 29, 2010 at 11:37 PM, Buck O Five <buckofive@...>
>> >> > wrote:
>> >> >> I'm not sure if this is the best approach so I'll just tell you what
>> >> >> I'm
>> >> >> trying to do and why I would want a notification that a conversation
>> >> >> has
>> >> >> ended.
>> >> >
>> >> > ConversationModerator component is used for notifying the client of
>> >> > conversation status. But I think your case is the opposite, it seems
>> >> > you want the notifications on the server side.
>> >> >
>> >> >> There are several case in my application where uploading a file or
>> >> >> files is
>> >> >> accompanied by a bean editor form, the catch is, file uploading is
>> >> >> handled
>> >> >> by swfUpload which is not associated with the form at all.  Meaning
>> >> >> the
>> >> >> files are uploaded in a separate post, which means I have to have
>> >> >> the
>> >> >> user
>> >> >> first submit the form so I can get the id of the new entity and then
>> >> >> allow
>> >> >> file uploads via swfupload.   So I was thinking maybe conversations
>> >> >> is
>> >> >> a
>> >> >> cleaner way to fix this clunky requirement so the user could upload
>> >> >> files
>> >> >> before the form is submitted.   The catch here would be deleting any
>> >> >> uploaded files (from disk) when a conversation has expired.  Is
>> >> >> there a
>> >> >> way
>> >> >> to do this, or maybe there is a better approach? Thanks for your
>> >> >> time
>> >> >> and
>> >> >> all your hard work with the new tynamo project.  It looks very
>> >> >> promising!
>> >> >
>> >> > Yes, from usability perspective you'd probably like to let your users
>> >> > start uploading the files right away, after which they can focus on
>> >> > filling in the other details on the form. There's a undocumented
>> >> > ConversationAware interface that can be used to invoke server-side
>> >> > actions on idle check when conversation's still active. If I get your
>> >> > requirement right, you want to delete the files in case the user had
>> >> > become idle (for which the rudimentary solutions is simple - you
>> >> > decide to delete after x mins if you haven't gotten the form back),
>> >> > but to make it user friendly, you don't want to set a hard limit but
>> >> > let the user work on the form *if* he's still there, right? Your use
>> >> > case is a bit complex for web environment, but together with
>> >> > ConversationModerator and ConversationAware you should be able to get
>> >> > this done. Basically, you'd use the ConversationModerator component
>> >> > and set its keepAlive to true, then let your page implement
>> >> > ConversationAware to reset your server side idle (which should be a
>> >> > bit longer than maxIdleSeconds you set for the conversation). Use
>> >> > Firebug to see how the requests behave and obviously you need to
>> >> > implement the watchdog thread for deleting the expired
>> >> > files-in-process yourself.
>> >> >
>> >> > Good luck and thanks for the compliments!
>> >> >
>> >> > Kalle
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe from this list, please visit:
>> >>
>> >>    http://xircles.codehaus.org/manage_email
>> >>
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>
Permalink | Reply |
headers
Buck O Five | 2 Feb 00:31
Picon

Re: Notifications when a t5 conversation has ended?

>>I understand  fairly well your requirement and agree it could be a useful
enhancement, so I could hack up something together fairly quickly.

If you have the time that would be fantastic! I'm pretty sure it will get used by others in the future too. 

I'm still going to take a look at the trunk, I'm curious to see the PersistentFieldStrategy in action.

On a completely different note are you guys going to be creating a component library?  Is tynamco looking for more commiters?  I ask because it sounds a lot like something I've been thinking of doing for a while.  I really feel there needs to be some serious T5 libs to make it successfull and to be bluntly honest whats out there now is lacking big time.   I have alot of components and have been working with T5 (everyday) since it was in early beta.  

Thanks for all the time you've spent already on this topic!

Permalink | Reply |
headers
Kalle Korhonen | 2 Feb 02:01
Picon

Re: Notifications when a t5 conversation has ended?

On Mon, Feb 1, 2010 at 3:31 PM, Buck O Five <buckofive@...> wrote:
> On a completely different note are you guys going to be creating a component
> library?  Is tynamco looking for more commiters?  I ask because it sounds a

General UI component library? That's a definite no - it's outside of
scope of Tynamo project. There's already really good project for that,
Chenillekit, also hosted at Codehaus
(http://chenillekit.codehaus.org). We use plenty of Chenillekit's
excellent components. You could simply offer your components to them,
I'm sure Massimo and Sven would appreciate help. We might offer some
specific components, like this ComponentModerator or, in the future
perhaps our own version of BeanEditForm & BeanDisplay, but any
components need to be related to and supporting our modules.

Kalle
Permalink | Reply |
headers
Buck O Five | 2 Feb 05:50
Picon

Re: Notifications when a t5 conversation has ended?

Hi Kalle,

So i've had a chance to play with the conversation for a bit today.  And I'm not quite sure what determines a conversation as being inactive as I'm getting unexpected results when trying to only allow 1 conversation as per the conversation guide. The results I'm seeing:

-  I get a new conversationId each time I refresh the browser
-  ConversationManagerImpl.discardConversation() isn't called until the idle time is up (which is what I expected, but i didn't expect conversationManager.isActiveConversation() to return false until then)

Here is my test case below.  Any help/guidance is much appreciated.

public class TestSingleConversation {
   
    <at> Inject private ConversationManager conversationManager;   
    <at> Inject private ComponentResources componentResources;

    <at> Persist("session") <at> Property
    private String conversationId;
   
    <at> Persist("conversation") <at> Property
    private Integer myConversationalProperty;
               
    public void onActivate()
    {         
          if (!conversationManager.isActiveConversation(conversationId))
          {
              conversationId = conversationManager.createConversation(componentResources.getPageName(), 60, true);
               myConversationalProperty = new Random().nextInt(10);
          }
    }
}

TestSingleConversation.tml:
<html xmlns:t="http://tapestry.apache.org/schema/tapestry_5_1_0.xsd"><head></head>
<body>
    conversationId: ${conversationId}
    test: ${myConversationalProperty}           
</body>
</html>




Permalink | Reply |
headers
Kalle Korhonen | 2 Feb 07:25
Picon

Re: Notifications when a t5 conversation has ended?

On Mon, Feb 1, 2010 at 8:50 PM, Buck O Five <buckofive@...> wrote:
> So i've had a chance to play with the conversation for a bit today.  And I'm
> not quite sure what determines a conversation as being inactive as I'm
> getting unexpected results when trying to only allow 1 conversation as per
> the conversation guide. The results I'm seeing:
> -  I get a new conversationId each time I refresh the browser

Certainly not the expected behavior, should be pretty easy to sort
out. Have you allowed cookies? Check what the value of the
conversation cookie is that your browser has. I'm going to put
together a GAE example for conversations in the next couple of days
anyway so I'll just check this case works as expected and that the
documentation is correct.

Kalle
Permalink | Reply |
headers
Buck O Five | 2 Feb 08:12
Picon

Re: Notifications when a t5 conversation has ended?

Thanks!  and to answer your question I tried it with cookies on and off with the same results.  

Another useful example would be how to incorporate additional contexts.  For example, a typical use case when using tapestry-hibernate is to also use the activation context like so:

public Object onActivate(MyHibernateEntity entity)
{
...
}

public String onPassivate() { 
   if(entity!=null)
      return entity.getId()

   return null;
}


So if possible, providing a clear example to this common case, I think would help jump start many newbies.   Thanks again and I'll check back in a few days.





On Mon, Feb 1, 2010 at 10:25 PM, Kalle Korhonen <kalle.o.korhonen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On Mon, Feb 1, 2010 at 8:50 PM, Buck O Five <buckofive-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> So i've had a chance to play with the conversation for a bit today.  And I'm
> not quite sure what determines a conversation as being inactive as I'm
> getting unexpected results when trying to only allow 1 conversation as per
> the conversation guide. The results I'm seeing:
> -  I get a new conversationId each time I refresh the browser

Certainly not the expected behavior, should be pretty easy to sort
out. Have you allowed cookies? Check what the value of the
conversation cookie is that your browser has. I'm going to put
together a GAE example for conversations in the next couple of days
anyway so I'll just check this case works as expected and that the
documentation is correct.

Kalle

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Permalink | Reply |
headers
Buck O Five | 12 Feb 03:02
Picon

Re: Notifications when a t5 conversation has ended?

Hi Kalle,
By any chance did you get to look at this?
thanks,
B

On Mon, Feb 1, 2010 at 10:25 PM, Kalle Korhonen <kalle.o.korhonen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On Mon, Feb 1, 2010 at 8:50 PM, Buck O Five <buckofive-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> So i've had a chance to play with the conversation for a bit today.  And I'm
> not quite sure what determines a conversation as being inactive as I'm
> getting unexpected results when trying to only allow 1 conversation as per
> the conversation guide. The results I'm seeing:
> -  I get a new conversationId each time I refresh the browser

Certainly not the expected behavior, should be pretty easy to sort
out. Have you allowed cookies? Check what the value of the
conversation cookie is that your browser has. I'm going to put
together a GAE example for conversations in the next couple of days
anyway so I'll just check this case works as expected and that the
documentation is correct.

Kalle

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Permalink | Reply |
headers
Kalle Korhonen | 12 Feb 09:29
Picon

Re: Notifications when a t5 conversation has ended?

On Thu, Feb 11, 2010 at 6:02 PM, Buck O Five <buckofive@...> wrote:
> By any chance did you get to look at this?

Oh yes. By any chance, you wouldn't happen to be using T5.2-SNAPSHOT?
The issue is that PageRenderRequestParameters.getLogicalPageName() now
returns the the page name without lower casing it and so it doesn't
match the already lowercased cookie name. I didn't test with any other
version yet, but I recall changing the case matching already once
because the logic changed in some earlier version. It's possible it
already broke in T5.1 with some combination of my changes. There's an
easy fix but not sure yet which way to go about it (I can see why
Howard seems to have been flip-flopping on it). There are some
benefits using the straight-up classname internally but supporting
previous version is easier if I just lowercase everywhere before
equals.

More than just tracking down the issue, I came up with a decent
example to showcase the cookie-based conversations and the enhanced
ConversationAware interface. I should have it ready in the next few
days. Please let me know which version of the big T you are using.

Kalle

> On Mon, Feb 1, 2010 at 10:25 PM, Kalle Korhonen <kalle.o.korhonen <at> gmail.com>
> wrote:
>>
>> On Mon, Feb 1, 2010 at 8:50 PM, Buck O Five <buckofive@...> wrote:
>> > So i've had a chance to play with the conversation for a bit today.  And
>> > I'm
>> > not quite sure what determines a conversation as being inactive as I'm
>> > getting unexpected results when trying to only allow 1 conversation as
>> > per
>> > the conversation guide. The results I'm seeing:
>> > -  I get a new conversationId each time I refresh the browser
>>
>> Certainly not the expected behavior, should be pretty easy to sort
>> out. Have you allowed cookies? Check what the value of the
>> conversation cookie is that your browser has. I'm going to put
>> together a GAE example for conversations in the next couple of days
>> anyway so I'll just check this case works as expected and that the
>> documentation is correct.
>>
>> Kalle
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>
Permalink | Reply |
headers
Kalle Korhonen | 12 Feb 20:15
Picon

Re: Notifications when a t5 conversation has ended?

Yeah, I verified that the differences between T5.1 and T5.2 is the
exact root cause. http://jira.codehaus.org/browse/TYNAMO-37 is the one
to follow - I'll fix it in the next version (0.1.1 due shortly) to
make it compatible for both.

Kalle

On Fri, Feb 12, 2010 at 12:29 AM, Kalle Korhonen
<kalle.o.korhonen@...> wrote:
> On Thu, Feb 11, 2010 at 6:02 PM, Buck O Five <buckofive@...> wrote:
>> By any chance did you get to look at this?
>
> Oh yes. By any chance, you wouldn't happen to be using T5.2-SNAPSHOT?
> The issue is that PageRenderRequestParameters.getLogicalPageName() now
> returns the the page name without lower casing it and so it doesn't
> match the already lowercased cookie name. I didn't test with any other
> version yet, but I recall changing the case matching already once
> because the logic changed in some earlier version. It's possible it
> already broke in T5.1 with some combination of my changes. There's an
> easy fix but not sure yet which way to go about it (I can see why
> Howard seems to have been flip-flopping on it). There are some
> benefits using the straight-up classname internally but supporting
> previous version is easier if I just lowercase everywhere before
> equals.
>
> More than just tracking down the issue, I came up with a decent
> example to showcase the cookie-based conversations and the enhanced
> ConversationAware interface. I should have it ready in the next few
> days. Please let me know which version of the big T you are using.
>
> Kalle
>
>
>> On Mon, Feb 1, 2010 at 10:25 PM, Kalle Korhonen <kalle.o.korhonen <at> gmail.com>
>> wrote:
>>>
>>> On Mon, Feb 1, 2010 at 8:50 PM, Buck O Five <buckofive@...> wrote:
>>> > So i've had a chance to play with the conversation for a bit today.  And
>>> > I'm
>>> > not quite sure what determines a conversation as being inactive as I'm
>>> > getting unexpected results when trying to only allow 1 conversation as
>>> > per
>>> > the conversation guide. The results I'm seeing:
>>> > -  I get a new conversationId each time I refresh the browser
>>>
>>> Certainly not the expected behavior, should be pretty easy to sort
>>> out. Have you allowed cookies? Check what the value of the
>>> conversation cookie is that your browser has. I'm going to put
>>> together a GAE example for conversations in the next couple of days
>>> anyway so I'll just check this case works as expected and that the
>>> documentation is correct.
>>>
>>> Kalle
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>
Permalink | Reply |
headers
Buck O Five | 13 Feb 03:34
Picon

Re: Notifications when a t5 conversation has ended?

Hi Kalle,
 
1st thanks for following up!  Yup, I am using T5.2-SNAPSHOT.  i'll keep an eye on issue TYNAMO-37!  good luck.


 
On Fri, Feb 12, 2010 at 11:15 AM, Kalle Korhonen <kalle.o.korhonen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Yeah, I verified that the differences between T5.1 and T5.2 is the
exact root cause. http://jira.codehaus.org/browse/TYNAMO-37 is the one
to follow - I'll fix it in the next version (0.1.1 due shortly) to
make it compatible for both.

Kalle


On Fri, Feb 12, 2010 at 12:29 AM, Kalle Korhonen
<kalle.o.korhonen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Feb 11, 2010 at 6:02 PM, Buck O Five <buckofive-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> By any chance did you get to look at this?
>
> Oh yes. By any chance, you wouldn't happen to be using T5.2-SNAPSHOT?
> The issue is that PageRenderRequestParameters.getLogicalPageName() now
> returns the the page name without lower casing it and so it doesn't
> match the already lowercased cookie name. I didn't test with any other
> version yet, but I recall changing the case matching already once
> because the logic changed in some earlier version. It's possible it
> already broke in T5.1 with some combination of my changes. There's an
> easy fix but not sure yet which way to go about it (I can see why
> Howard seems to have been flip-flopping on it). There are some
> benefits using the straight-up classname internally but supporting
> previous version is easier if I just lowercase everywhere before
> equals.
>
> More than just tracking down the issue, I came up with a decent
> example to showcase the cookie-based conversations and the enhanced
> ConversationAware interface. I should have it ready in the next few
> days. Please let me know which version of the big T you are using.
>
> Kalle
>
>
>> On Mon, Feb 1, 2010 at 10:25 PM, Kalle Korhonen <kalle.o.korhonen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> wrote:
>>>
>>> On Mon, Feb 1, 2010 at 8:50 PM, Buck O Five <buckofive <at> gmail.com> wrote:
>>> > So i've had a chance to play with the conversation for a bit today.  And
>>> > I'm
>>> > not quite sure what determines a conversation as being inactive as I'm
>>> > getting unexpected results when trying to only allow 1 conversation as
>>> > per
>>> > the conversation guide. The results I'm seeing:
>>> > -  I get a new conversationId each time I refresh the browser
>>>
>>> Certainly not the expected behavior, should be pretty easy to sort
>>> out. Have you allowed cookies? Check what the value of the
>>> conversation cookie is that your browser has. I'm going to put
>>> together a GAE example for conversations in the next couple of days
>>> anyway so I'll just check this case works as expected and that the
>>> documentation is correct.
>>>
>>> Kalle
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Permalink | Reply |
headers
Kalle Korhonen | 13 Feb 21:08
Picon

Re: Notifications when a t5 conversation has ended?

Oh I don't think luck's needed. TYNAMO-37 is already fixed and I'm
working on TYNAMO-35 and TYNAMO-36 - related to enhancing
ConversationAware interfance and cookie-based conversations. This is
where you can take part in it if you like. I've already committed the
planned changes to the ConversationAware interface and added an
example of its usage as part of tynamo-example-conversations.
Personally, I like how it turned out - the enhanced interface contains
two new signatures:
	public void onConversationCreated(Conversation conversation);

	public void onConversationEnded(Conversation conversation, boolean expired);

It's still revolves around three three identifying keys: sessionid,
conversationid and pagename as I noted earlier but they are all neatly
wrapped inside the Conversation object that was previously internal
only. The concept is that arbitrary services can register to listen
for these events for particular pages - that part of the
implementation and actually receiving the notifications isn't done
yet, but the example makes use of the new interface and it should be
easy to undertand the logic behind it. The snapshots are available
from http://ci.repository.codehaus.org/ (see the guide at
http://tynamo.org/tapestry-conversations+guide for more information
about it)

Kalle

On Fri, Feb 12, 2010 at 6:34 PM, Buck O Five <buckofive@...> wrote:
> Hi Kalle,
>
> 1st thanks for following up!  Yup, I am using T5.2-SNAPSHOT.  i'll keep an
> eye on issue TYNAMO-37!  good luck.
>
>
> On Fri, Feb 12, 2010 at 11:15 AM, Kalle Korhonen
> <kalle.o.korhonen@...> wrote:
>>
>> Yeah, I verified that the differences between T5.1 and T5.2 is the
>> exact root cause. http://jira.codehaus.org/browse/TYNAMO-37 is the one
>> to follow - I'll fix it in the next version (0.1.1 due shortly) to
>> make it compatible for both.
>>
>> Kalle
>>
>>
>> On Fri, Feb 12, 2010 at 12:29 AM, Kalle Korhonen
>> <kalle.o.korhonen@...> wrote:
>> > On Thu, Feb 11, 2010 at 6:02 PM, Buck O Five <buckofive@...>
>> > wrote:
>> >> By any chance did you get to look at this?
>> >
>> > Oh yes. By any chance, you wouldn't happen to be using T5.2-SNAPSHOT?
>> > The issue is that PageRenderRequestParameters.getLogicalPageName() now
>> > returns the the page name without lower casing it and so it doesn't
>> > match the already lowercased cookie name. I didn't test with any other
>> > version yet, but I recall changing the case matching already once
>> > because the logic changed in some earlier version. It's possible it
>> > already broke in T5.1 with some combination of my changes. There's an
>> > easy fix but not sure yet which way to go about it (I can see why
>> > Howard seems to have been flip-flopping on it). There are some
>> > benefits using the straight-up classname internally but supporting
>> > previous version is easier if I just lowercase everywhere before
>> > equals.
>> >
>> > More than just tracking down the issue, I came up with a decent
>> > example to showcase the cookie-based conversations and the enhanced
>> > ConversationAware interface. I should have it ready in the next few
>> > days. Please let me know which version of the big T you are using.
>> >
>> > Kalle
>> >
>> >
>> >> On Mon, Feb 1, 2010 at 10:25 PM, Kalle Korhonen
>> >> <kalle.o.korhonen@...>
>> >> wrote:
>> >>>
>> >>> On Mon, Feb 1, 2010 at 8:50 PM, Buck O Five <buckofive@...>
>> >>> wrote:
>> >>> > So i've had a chance to play with the conversation for a bit today.
>> >>> > And
>> >>> > I'm
>> >>> > not quite sure what determines a conversation as being inactive as
>> >>> > I'm
>> >>> > getting unexpected results when trying to only allow 1 conversation
>> >>> > as
>> >>> > per
>> >>> > the conversation guide. The results I'm seeing:
>> >>> > -  I get a new conversationId each time I refresh the browser
>> >>>
>> >>> Certainly not the expected behavior, should be pretty easy to sort
>> >>> out. Have you allowed cookies? Check what the value of the
>> >>> conversation cookie is that your browser has. I'm going to put
>> >>> together a GAE example for conversations in the next couple of days
>> >>> anyway so I'll just check this case works as expected and that the
>> >>> documentation is correct.
>> >>>
>> >>> Kalle
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe from this list, please visit:
>> >>>
>> >>>    http://xircles.codehaus.org/manage_email
>> >>>
>> >>>
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>
Permalink | Reply |
headers
Kalle Korhonen | 16 Feb 06:09
Picon

Re: Notifications when a t5 conversation has ended?

I finished the initial implementation for the notifications, including
making it possible to simply contribute listeners for the
page-specific conversations events and making a working example that
takes advantage of the notifications. Compared to Seam/Weld
conversations the advantage is that the core doesn't spawn additional
threads so it'll run on GAE for example (compare to
https://jira.jboss.org/jira/browse/WELDX-73).

Kalle

On Sat, Feb 13, 2010 at 12:08 PM, Kalle Korhonen
<kalle.o.korhonen@...> wrote:
> Oh I don't think luck's needed. TYNAMO-37 is already fixed and I'm
> working on TYNAMO-35 and TYNAMO-36 - related to enhancing
> ConversationAware interfance and cookie-based conversations. This is
> where you can take part in it if you like. I've already committed the
> planned changes to the ConversationAware interface and added an
> example of its usage as part of tynamo-example-conversations.
> Personally, I like how it turned out - the enhanced interface contains
> two new signatures:
>        public void onConversationCreated(Conversation conversation);
>
>        public void onConversationEnded(Conversation conversation, boolean expired);
>
> It's still revolves around three three identifying keys: sessionid,
> conversationid and pagename as I noted earlier but they are all neatly
> wrapped inside the Conversation object that was previously internal
> only. The concept is that arbitrary services can register to listen
> for these events for particular pages - that part of the
> implementation and actually receiving the notifications isn't done
> yet, but the example makes use of the new interface and it should be
> easy to undertand the logic behind it. The snapshots are available
> from http://ci.repository.codehaus.org/ (see the guide at
> http://tynamo.org/tapestry-conversations+guide for more information
> about it)
>
> Kalle
>
>
>
> On Fri, Feb 12, 2010 at 6:34 PM, Buck O Five <buckofive@...> wrote:
>> Hi Kalle,
>>
>> 1st thanks for following up!  Yup, I am using T5.2-SNAPSHOT.  i'll keep an
>> eye on issue TYNAMO-37!  good luck.
>>
>>
>> On Fri, Feb 12, 2010 at 11:15 AM, Kalle Korhonen
>> <kalle.o.korhonen@...> wrote:
>>>
>>> Yeah, I verified that the differences between T5.1 and T5.2 is the
>>> exact root cause. http://jira.codehaus.org/browse/TYNAMO-37 is the one
>>> to follow - I'll fix it in the next version (0.1.1 due shortly) to
>>> make it compatible for both.
>>>
>>> Kalle
>>>
>>>
>>> On Fri, Feb 12, 2010 at 12:29 AM, Kalle Korhonen
>>> <kalle.o.korhonen@...> wrote:
>>> > On Thu, Feb 11, 2010 at 6:02 PM, Buck O Five <buckofive@...>
>>> > wrote:
>>> >> By any chance did you get to look at this?
>>> >
>>> > Oh yes. By any chance, you wouldn't happen to be using T5.2-SNAPSHOT?
>>> > The issue is that PageRenderRequestParameters.getLogicalPageName() now
>>> > returns the the page name without lower casing it and so it doesn't
>>> > match the already lowercased cookie name. I didn't test with any other
>>> > version yet, but I recall changing the case matching already once
>>> > because the logic changed in some earlier version. It's possible it
>>> > already broke in T5.1 with some combination of my changes. There's an
>>> > easy fix but not sure yet which way to go about it (I can see why
>>> > Howard seems to have been flip-flopping on it). There are some
>>> > benefits using the straight-up classname internally but supporting
>>> > previous version is easier if I just lowercase everywhere before
>>> > equals.
>>> >
>>> > More than just tracking down the issue, I came up with a decent
>>> > example to showcase the cookie-based conversations and the enhanced
>>> > ConversationAware interface. I should have it ready in the next few
>>> > days. Please let me know which version of the big T you are using.
>>> >
>>> > Kalle
>>> >
>>> >
>>> >> On Mon, Feb 1, 2010 at 10:25 PM, Kalle Korhonen
>>> >> <kalle.o.korhonen@...>
>>> >> wrote:
>>> >>>
>>> >>> On Mon, Feb 1, 2010 at 8:50 PM, Buck O Five <buckofive@...>
>>> >>> wrote:
>>> >>> > So i've had a chance to play with the conversation for a bit today.
>>> >>> > And
>>> >>> > I'm
>>> >>> > not quite sure what determines a conversation as being inactive as
>>> >>> > I'm
>>> >>> > getting unexpected results when trying to only allow 1 conversation
>>> >>> > as
>>> >>> > per
>>> >>> > the conversation guide. The results I'm seeing:
>>> >>> > -  I get a new conversationId each time I refresh the browser
>>> >>>
>>> >>> Certainly not the expected behavior, should be pretty easy to sort
>>> >>> out. Have you allowed cookies? Check what the value of the
>>> >>> conversation cookie is that your browser has. I'm going to put
>>> >>> together a GAE example for conversations in the next couple of days
>>> >>> anyway so I'll just check this case works as expected and that the
>>> >>> documentation is correct.
>>> >>>
>>> >>> Kalle
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe from this list, please visit:
>>> >>>
>>> >>>    http://xircles.codehaus.org/manage_email
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>
Permalink | Reply |
headers
Buck O Five | 18 Feb 03:09
Picon

Re: Notifications when a t5 conversation has ended?

Wow, this sounds great.  I'll be working on this again tomorrow,  I'll let you know how it goes.  Thanks for all your hard work (its much appreciated)!


 
On Mon, Feb 15, 2010 at 9:09 PM, Kalle Korhonen <kalle.o.korhonen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I finished the initial implementation for the notifications, including
making it possible to simply contribute listeners for the
page-specific conversations events and making a working example that
takes advantage of the notifications. Compared to Seam/Weld
conversations the advantage is that the core doesn't spawn additional
threads so it'll run on GAE for example (compare to
https://jira.jboss.org/jira/browse/WELDX-73).

Kalle


On Sat, Feb 13, 2010 at 12:08 PM, Kalle Korhonen
<kalle.o.korhonen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Oh I don't think luck's needed. TYNAMO-37 is already fixed and I'm
> working on TYNAMO-35 and TYNAMO-36 - related to enhancing
> ConversationAware interfance and cookie-based conversations. This is
> where you can take part in it if you like. I've already committed the
> planned changes to the ConversationAware interface and added an
> example of its usage as part of tynamo-example-conversations.
> Personally, I like how it turned out - the enhanced interface contains
> two new signatures:
>        public void onConversationCreated(Conversation conversation);
>
>        public void onConversationEnded(Conversation conversation, boolean expired);
>
> It's still revolves around three three identifying keys: sessionid,
> conversationid and pagename as I noted earlier but they are all neatly
> wrapped inside the Conversation object that was previously internal
> only. The concept is that arbitrary services can register to listen
> for these events for particular pages - that part of the
> implementation and actually receiving the notifications isn't done
> yet, but the example makes use of the new interface and it should be
> easy to undertand the logic behind it. The snapshots are available
> from http://ci.repository.codehaus.org/ (see the guide at
> http://tynamo.org/tapestry-conversations+guide for more information
> about it)
>
> Kalle
>
>
>
> On Fri, Feb 12, 2010 at 6:34 PM, Buck O Five <buckofive-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Hi Kalle,
>>
>> 1st thanks for following up!  Yup, I am using T5.2-SNAPSHOT.  i'll keep an
>> eye on issue TYNAMO-37!  good luck.
>>
>>
>> On Fri, Feb 12, 2010 at 11:15 AM, Kalle Korhonen
>> <kalle.o.korhonen <at> gmail.com> wrote:
>>>
>>> Yeah, I verified that the differences between T5.1 and T5.2 is the
>>> exact root cause. http://jira.codehaus.org/browse/TYNAMO-37 is the one
>>> to follow - I'll fix it in the next version (0.1.1 due shortly) to
>>> make it compatible for both.
>>>
>>> Kalle
>>>
>>>
>>> On Fri, Feb 12, 2010 at 12:29 AM, Kalle Korhonen
>>> <kalle.o.korhonen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> > On Thu, Feb 11, 2010 at 6:02 PM, Buck O Five <buckofive <at> gmail.com>
>>> > wrote:
>>> >> By any chance did you get to look at this?
>>> >
>>> > Oh yes. By any chance, you wouldn't happen to be using T5.2-SNAPSHOT?
>>> > The issue is that PageRenderRequestParameters.getLogicalPageName() now
>>> > returns the the page name without lower casing it and so it doesn't
>>> > match the already lowercased cookie name. I didn't test with any other
>>> > version yet, but I recall changing the case matching already once
>>> > because the logic changed in some earlier version. It's possible it
>>> > already broke in T5.1 with some combination of my changes. There's an
>>> > easy fix but not sure yet which way to go about it (I can see why
>>> > Howard seems to have been flip-flopping on it). There are some
>>> > benefits using the straight-up classname internally but supporting
>>> > previous version is easier if I just lowercase everywhere before
>>> > equals.
>>> >
>>> > More than just tracking down the issue, I came up with a decent
>>> > example to showcase the cookie-based conversations and the enhanced
>>> > ConversationAware interface. I should have it ready in the next few
>>> > days. Please let me know which version of the big T you are using.
>>> >
>>> > Kalle
>>> >
>>> >
>>> >> On Mon, Feb 1, 2010 at 10:25 PM, Kalle Korhonen
>>> >> <kalle.o.korhonen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> >> wrote:
>>> >>>
>>> >>> On Mon, Feb 1, 2010 at 8:50 PM, Buck O Five <buckofive-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> >>> wrote:
>>> >>> > So i've had a chance to play with the conversation for a bit today.
>>> >>> > And
>>> >>> > I'm
>>> >>> > not quite sure what determines a conversation as being inactive as
>>> >>> > I'm
>>> >>> > getting unexpected results when trying to only allow 1 conversation
>>> >>> > as
>>> >>> > per
>>> >>> > the conversation guide. The results I'm seeing:
>>> >>> > -  I get a new conversationId each time I refresh the browser
>>> >>>
>>> >>> Certainly not the expected behavior, should be pretty easy to sort
>>> >>> out. Have you allowed cookies? Check what the value of the
>>> >>> conversation cookie is that your browser has. I'm going to put
>>> >>> together a GAE example for conversations in the next couple of days
>>> >>> anyway so I'll just check this case works as expected and that the
>>> >>> documentation is correct.
>>> >>>
>>> >>> Kalle
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe from this list, please visit:
>>> >>>
>>> >>>    http://xircles.codehaus.org/manage_email
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Permalink | Reply |
headers
Kalle Korhonen | 4 Mar 05:23
Picon

Re: Notifications when a t5 conversation has ended?

Just FYI, I'm thinking about releasing a new version of
tapestry-conversations with the discussed changes included in the next
few days. Didn't receive any additional feedback or complaints so I
have to assume all is well :)

Kalle

On Wed, Feb 17, 2010 at 6:09 PM, Buck O Five <buckofive@...> wrote:
> Wow, this sounds great.  I'll be working on this again tomorrow,  I'll let
> you know how it goes.  Thanks for all your hard work (its much appreciated)!
>
>
> On Mon, Feb 15, 2010 at 9:09 PM, Kalle Korhonen <kalle.o.korhonen <at> gmail.com>
> wrote:
>>
>> I finished the initial implementation for the notifications, including
>> making it possible to simply contribute listeners for the
>> page-specific conversations events and making a working example that
>> takes advantage of the notifications. Compared to Seam/Weld
>> conversations the advantage is that the core doesn't spawn additional
>> threads so it'll run on GAE for example (compare to
>> https://jira.jboss.org/jira/browse/WELDX-73).
>>
>> Kalle
>>
>>
>> On Sat, Feb 13, 2010 at 12:08 PM, Kalle Korhonen
>> <kalle.o.korhonen@...> wrote:
>> > Oh I don't think luck's needed. TYNAMO-37 is already fixed and I'm
>> > working on TYNAMO-35 and TYNAMO-36 - related to enhancing
>> > ConversationAware interfance and cookie-based conversations. This is
>> > where you can take part in it if you like. I've already committed the
>> > planned changes to the ConversationAware interface and added an
>> > example of its usage as part of tynamo-example-conversations.
>> > Personally, I like how it turned out - the enhanced interface contains
>> > two new signatures:
>> >        public void onConversationCreated(Conversation conversation);
>> >
>> >        public void onConversationEnded(Conversation conversation,
>> > boolean expired);
>> >
>> > It's still revolves around three three identifying keys: sessionid,
>> > conversationid and pagename as I noted earlier but they are all neatly
>> > wrapped inside the Conversation object that was previously internal
>> > only. The concept is that arbitrary services can register to listen
>> > for these events for particular pages - that part of the
>> > implementation and actually receiving the notifications isn't done
>> > yet, but the example makes use of the new interface and it should be
>> > easy to undertand the logic behind it. The snapshots are available
>> > from http://ci.repository.codehaus.org/ (see the guide at
>> > http://tynamo.org/tapestry-conversations+guide for more information
>> > about it)
>> >
>> > Kalle
>> >
>> >
>> >
>> > On Fri, Feb 12, 2010 at 6:34 PM, Buck O Five <buckofive@...>
>> > wrote:
>> >> Hi Kalle,
>> >>
>> >> 1st thanks for following up!  Yup, I am using T5.2-SNAPSHOT.  i'll keep
>> >> an
>> >> eye on issue TYNAMO-37!  good luck.
>> >>
>> >>
>> >> On Fri, Feb 12, 2010 at 11:15 AM, Kalle Korhonen
>> >> <kalle.o.korhonen@...> wrote:
>> >>>
>> >>> Yeah, I verified that the differences between T5.1 and T5.2 is the
>> >>> exact root cause. http://jira.codehaus.org/browse/TYNAMO-37 is the one
>> >>> to follow - I'll fix it in the next version (0.1.1 due shortly) to
>> >>> make it compatible for both.
>> >>>
>> >>> Kalle
>> >>>
>> >>>
>> >>> On Fri, Feb 12, 2010 at 12:29 AM, Kalle Korhonen
>> >>> <kalle.o.korhonen@...> wrote:
>> >>> > On Thu, Feb 11, 2010 at 6:02 PM, Buck O Five <buckofive@...>
>> >>> > wrote:
>> >>> >> By any chance did you get to look at this?
>> >>> >
>> >>> > Oh yes. By any chance, you wouldn't happen to be using
>> >>> > T5.2-SNAPSHOT?
>> >>> > The issue is that PageRenderRequestParameters.getLogicalPageName()
>> >>> > now
>> >>> > returns the the page name without lower casing it and so it doesn't
>> >>> > match the already lowercased cookie name. I didn't test with any
>> >>> > other
>> >>> > version yet, but I recall changing the case matching already once
>> >>> > because the logic changed in some earlier version. It's possible it
>> >>> > already broke in T5.1 with some combination of my changes. There's
>> >>> > an
>> >>> > easy fix but not sure yet which way to go about it (I can see why
>> >>> > Howard seems to have been flip-flopping on it). There are some
>> >>> > benefits using the straight-up classname internally but supporting
>> >>> > previous version is easier if I just lowercase everywhere before
>> >>> > equals.
>> >>> >
>> >>> > More than just tracking down the issue, I came up with a decent
>> >>> > example to showcase the cookie-based conversations and the enhanced
>> >>> > ConversationAware interface. I should have it ready in the next few
>> >>> > days. Please let me know which version of the big T you are using.
>> >>> >
>> >>> > Kalle
>> >>> >
>> >>> >
>> >>> >> On Mon, Feb 1, 2010 at 10:25 PM, Kalle Korhonen
>> >>> >> <kalle.o.korhonen@...>
>> >>> >> wrote:
>> >>> >>>
>> >>> >>> On Mon, Feb 1, 2010 at 8:50 PM, Buck O Five <buckofive@...>
>> >>> >>> wrote:
>> >>> >>> > So i've had a chance to play with the conversation for a bit
>> >>> >>> > today.
>> >>> >>> > And
>> >>> >>> > I'm
>> >>> >>> > not quite sure what determines a conversation as being inactive
>> >>> >>> > as
>> >>> >>> > I'm
>> >>> >>> > getting unexpected results when trying to only allow 1
>> >>> >>> > conversation
>> >>> >>> > as
>> >>> >>> > per
>> >>> >>> > the conversation guide. The results I'm seeing:
>> >>> >>> > -  I get a new conversationId each time I refresh the browser
>> >>> >>>
>> >>> >>> Certainly not the expected behavior, should be pretty easy to sort
>> >>> >>> out. Have you allowed cookies? Check what the value of the
>> >>> >>> conversation cookie is that your browser has. I'm going to put
>> >>> >>> together a GAE example for conversations in the next couple of
>> >>> >>> days
>> >>> >>> anyway so I'll just check this case works as expected and that the
>> >>> >>> documentation is correct.
>> >>> >>>
>> >>> >>> Kalle
>> >>> >>>
>> >>> >>>
>> >>> >>> ---------------------------------------------------------------------
>> >>> >>> To unsubscribe from this list, please visit:
>> >>> >>>
>> >>> >>>    http://xircles.codehaus.org/manage_email
>> >>> >>>
>> >>> >>>
>> >>> >>
>> >>> >>
>> >>> >
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe from this list, please visit:
>> >>>
>> >>>    http://xircles.codehaus.org/manage_email
>> >>>
>> >>>
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>
Permalink | Reply |

Gmane