Re: T5: Is Persist(conversation) planned? Please?
For most people, I'm sure it'd be Seam. Spring adds an extra layer of indirection, another IoC framework, more cumbersome configuration and support for other patterns that a few people really need. Not that I have anything against Spring (quite the contrary, I happily use it in multiple projects), but T5 with its advanced IoC, Seam and a few other supporting projects like c3p0 have been eating away what Spring has to offer to a point where it's not clear what the advantage is. Certainly, one answer is that it still supports many more frameworks and configurations, but that mostly makes it more complex, not easier for the user. Kalle On 11/30/07, Angelo Chen [EMAIL PROTECTED] wrote: Hi Kalle, I found this suggestion interesting, T5 already has Spring integration, which one will be easier for the user, Seam or Spring? A.C. Kalle Korhonen-2 wrote: JSF. In practice, integrating Tap5 with Seam might be the fastest way of getting practical results for a conversational scope, and wouldn't solve only one but two problems at the same time (conversations and session-per-conversation), of course at the expense of tying the -- View this message in context: http://www.nabble.com/T5%3A-Is-Persist%28%22conversation%22%29-planned---Please--tf4888105.html#a14042379 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Is Persist(conversation) planned? Please?
On 11/30/07, Geoff Callender [EMAIL PROTECTED] wrote: I hadn't considered for a second that Tapestry could, or even should, be integrated with Seam, but it's a wild idea that just might make sense! Just had a look at the Wicket-Seam Integration code and at first blush it looks like Tapestry-Seam would be very doable. I would really love to dig further into this, but I very much doubt I could find the time. Ideally it would be done by someone who already has a good handle on Seam. Anyone out there keen to take this on?? Same here, I've been browsing Wicket-Seam code as well. I have some usage experience of Seam, but not in-depth knowledge of the internals. Does Tapestry have the equivalent of the wicket-stuff development area? Should it? http://wicketstuff.org/confluence/display/STUFFWEB/Home Probably relevant to cross-link the Trails 2.0 discussions here: http://archive.trails.codehaus.org/dev/e1cf626e0711300032h252f23afk1b2b14b5292c880c%40mail.gmail.com A full-stack web framework integration project (Steam?) might be the right place for T5-Seam support. All of this very much just talk at this point, but I may have some time freeing up for this early(ish) next year. Kalle On 30/11/2007, at 12:01 PM, Kalle Korhonen wrote: Of course, nothing prevents one writing a semi-automatic workspace management layer on top of Seam that would take care of detecting and closing abandoned conversations (for example, along the lines I suggested on the Trails list). The Seam guys have carefully removed any dependencies to JSF. In practice, integrating Tap5 with Seam might be the fastest way of getting practical results for a conversational scope, and wouldn't solve only one but two problems at the same time (conversations and session-per-conversation), of course at the expense of tying the implementation more closely with Hibernate or at least JPA, but that's probably what the majority is using anyway. I'm sure the Seam guys would love to see Tapestry support for Seam. And btw, Wicket guys have already done this. Given that you Geoff are probably inclined to use J2EE container anyway, wouldn't it make sense to you to start looking at creating tapestry-seam integration project? It might be an interesting project to take on for me as well. Kalle On 11/28/07, Kalle Korhonen [EMAIL PROTECTED] wrote: I completely agree with Geoff that a good-enough generic support for conversations could make developing web applications much easier and it's one of the remaining big issues that web frameworks typically don't offer a solution for out-of-the-box. Seam's got a solution that works well for typical enterprise apps that may have high amount of interaction with the database but don't have a huge number of users. While Seam ignores the problem of closing abandoned conversations, it'll quickly lead to much higher memory consumption as open conversations generally occupy memory until explicitly closed or the session is expired. There's been various tries at solving the conversation support for Tapestry and we are planning on supporting conversation in Trails with a tighter memory management model for better scalability. I've written some notes on session-per-conversation at http://archive.trails.codehaus.org/users/[EMAIL PROTECTED]'s relevant for this discussion as well. For Tap5, you can of course come up with your own solution, but it'd be great if the framework had a generic support for conversations that would work well enough in the most common cases out-of-the-box and could be extended. Kalle On 11/28/07, Thiago HP [EMAIL PROTECTED] wrote: On 11/28/07, Francois Armand [EMAIL PROTECTED] wrote: I completely agree with your remarks, and it's a kind of pity that T5 is such in advance in so many areas, and in the same time have to deals by hand with that. Let's not forget that Tapestry 5 is still alpha and there are other areas needing work too, AJAX being one of the most anticipated ones. In addition, it has a very flexible architecture that allows developers (Howard, other T5 comitters or me or you) to implement any missing feature. ;) Thiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Is Persist(conversation) planned? Please?
This is exactly what I am using, it is a wrapper around LinkedHashMap that someone else developed here: http://www.source-code.biz/snippets/java/6.htm I think I also used an LRU put out by SUN in my previous versions. On Nov 30, 2007 9:13 AM, Christian Edward Gruber [EMAIL PROTECTED] wrote: If you just override removeEldestEntry() on LinkedHashMap, you'll get LRU behaviour. You can subclass it and set a max capacity, and LRU if you've hit capacity. Not a heavy implementation, but it might reduce a dependency if you're only importing commons-collections for the LRU. christian. On 30-Nov-07, at 8:34 AM, Daniel Jue wrote: I have a primitive caching implementation that I like to think of as a conversation, even though it is not comparable to the kinds of persistence methods you guys are talking about. Mine involves storing large computed data in the User's ASO (such as a report data structure with it's data). Inside the User's ASO, I have a LRU Hashmap (copied one off the net) that acts as the cache. I use very unsophisticated but unique keys, which are the SQL used to generate that specific report data. The LRU has an upper limit (like 5), and for the 6th report run by that user, it just forgets the one that has been least used. I have a common page to display all reports, and that page checks the User's LRU cache before trying to execute a 30 second SQL request. Before the report page is called, I copy some data from the user's selections into the new page instance. That data uses regular @Persist. From that data, the page can calculate the key (the SQL) and then check for cached data OnSetup. So this works for up to (n=5) windows, and it's snappy if the same report has been recently run by the user. Wow it sounds a lot more complicated-but-elementary when I write it out. Come to think of it--I should just @Persist the key value, which is smaller than the all the setting data used to construct the key. PS-- if you see something very wrong about this picture, please let me know! Daniel Jue On Nov 29, 2007 8:01 PM, Kalle Korhonen [EMAIL PROTECTED] wrote: Of course, nothing prevents one writing a semi-automatic workspace management layer on top of Seam that would take care of detecting and closing abandoned conversations (for example, along the lines I suggested on the Trails list). The Seam guys have carefully removed any dependencies to JSF. In practice, integrating Tap5 with Seam might be the fastest way of getting practical results for a conversational scope, and wouldn't solve only one but two problems at the same time (conversations and session-per-conversation), of course at the expense of tying the implementation more closely with Hibernate or at least JPA, but that's probably what the majority is using anyway. I'm sure the Seam guys would love to see Tapestry support for Seam. And btw, Wicket guys have already done this. Given that you Geoff are probably inclined to use J2EE container anyway, wouldn't it make sense to you to start looking at creating tapestry-seam integration project? It might be an interesting project to take on for me as well. Kalle On 11/28/07, Kalle Korhonen [EMAIL PROTECTED] wrote: I completely agree with Geoff that a good-enough generic support for conversations could make developing web applications much easier and it's one of the remaining big issues that web frameworks typically don't offer a solution for out-of-the-box. Seam's got a solution that works well for typical enterprise apps that may have high amount of interaction with the database but don't have a huge number of users. While Seam ignores the problem of closing abandoned conversations, it'll quickly lead to much higher memory consumption as open conversations generally occupy memory until explicitly closed or the session is expired. There's been various tries at solving the conversation support for Tapestry and we are planning on supporting conversation in Trails with a tighter memory management model for better scalability. I've written some notes on session-per-conversation at http://archive.trails.codehaus.org/users/[EMAIL PROTECTED]'s relevant for this discussion as well. For Tap5, you can of course come up with your own solution, but it'd be great if the framework had a generic support for conversations that would work well enough in the most common cases out-of-the-box and could be extended. Kalle On 11/28/07, Thiago HP [EMAIL PROTECTED] wrote: On 11/28/07, Francois Armand [EMAIL PROTECTED] wrote: I completely agree with your remarks, and it's a kind of pity that T5 is such in advance in so many areas, and in the same time have to deals by hand with that. Let's not forget that Tapestry 5 is still alpha and there are other areas needing work too, AJAX being one of
Re: T5: Is Persist(conversation) planned? Please?
If you just override removeEldestEntry() on LinkedHashMap, you'll get LRU behaviour. You can subclass it and set a max capacity, and LRU if you've hit capacity. Not a heavy implementation, but it might reduce a dependency if you're only importing commons-collections for the LRU. christian. On 30-Nov-07, at 8:34 AM, Daniel Jue wrote: I have a primitive caching implementation that I like to think of as a conversation, even though it is not comparable to the kinds of persistence methods you guys are talking about. Mine involves storing large computed data in the User's ASO (such as a report data structure with it's data). Inside the User's ASO, I have a LRU Hashmap (copied one off the net) that acts as the cache. I use very unsophisticated but unique keys, which are the SQL used to generate that specific report data. The LRU has an upper limit (like 5), and for the 6th report run by that user, it just forgets the one that has been least used. I have a common page to display all reports, and that page checks the User's LRU cache before trying to execute a 30 second SQL request. Before the report page is called, I copy some data from the user's selections into the new page instance. That data uses regular @Persist. From that data, the page can calculate the key (the SQL) and then check for cached data OnSetup. So this works for up to (n=5) windows, and it's snappy if the same report has been recently run by the user. Wow it sounds a lot more complicated-but-elementary when I write it out. Come to think of it--I should just @Persist the key value, which is smaller than the all the setting data used to construct the key. PS-- if you see something very wrong about this picture, please let me know! Daniel Jue On Nov 29, 2007 8:01 PM, Kalle Korhonen [EMAIL PROTECTED] wrote: Of course, nothing prevents one writing a semi-automatic workspace management layer on top of Seam that would take care of detecting and closing abandoned conversations (for example, along the lines I suggested on the Trails list). The Seam guys have carefully removed any dependencies to JSF. In practice, integrating Tap5 with Seam might be the fastest way of getting practical results for a conversational scope, and wouldn't solve only one but two problems at the same time (conversations and session-per-conversation), of course at the expense of tying the implementation more closely with Hibernate or at least JPA, but that's probably what the majority is using anyway. I'm sure the Seam guys would love to see Tapestry support for Seam. And btw, Wicket guys have already done this. Given that you Geoff are probably inclined to use J2EE container anyway, wouldn't it make sense to you to start looking at creating tapestry-seam integration project? It might be an interesting project to take on for me as well. Kalle On 11/28/07, Kalle Korhonen [EMAIL PROTECTED] wrote: I completely agree with Geoff that a good-enough generic support for conversations could make developing web applications much easier and it's one of the remaining big issues that web frameworks typically don't offer a solution for out-of-the-box. Seam's got a solution that works well for typical enterprise apps that may have high amount of interaction with the database but don't have a huge number of users. While Seam ignores the problem of closing abandoned conversations, it'll quickly lead to much higher memory consumption as open conversations generally occupy memory until explicitly closed or the session is expired. There's been various tries at solving the conversation support for Tapestry and we are planning on supporting conversation in Trails with a tighter memory management model for better scalability. I've written some notes on session-per-conversation at http://archive.trails.codehaus.org/users/[EMAIL PROTECTED]'s relevant for this discussion as well. For Tap5, you can of course come up with your own solution, but it'd be great if the framework had a generic support for conversations that would work well enough in the most common cases out-of-the-box and could be extended. Kalle On 11/28/07, Thiago HP [EMAIL PROTECTED] wrote: On 11/28/07, Francois Armand [EMAIL PROTECTED] wrote: I completely agree with your remarks, and it's a kind of pity that T5 is such in advance in so many areas, and in the same time have to deals by hand with that. Let's not forget that Tapestry 5 is still alpha and there are other areas needing work too, AJAX being one of the most anticipated ones. In addition, it has a very flexible architecture that allows developers (Howard, other T5 comitters or me or you) to implement any missing feature. ;) Thiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To
Re: T5: Is Persist(conversation) planned? Please?
I have a primitive caching implementation that I like to think of as a conversation, even though it is not comparable to the kinds of persistence methods you guys are talking about. Mine involves storing large computed data in the User's ASO (such as a report data structure with it's data). Inside the User's ASO, I have a LRU Hashmap (copied one off the net) that acts as the cache. I use very unsophisticated but unique keys, which are the SQL used to generate that specific report data. The LRU has an upper limit (like 5), and for the 6th report run by that user, it just forgets the one that has been least used. I have a common page to display all reports, and that page checks the User's LRU cache before trying to execute a 30 second SQL request. Before the report page is called, I copy some data from the user's selections into the new page instance. That data uses regular @Persist. From that data, the page can calculate the key (the SQL) and then check for cached data OnSetup. So this works for up to (n=5) windows, and it's snappy if the same report has been recently run by the user. Wow it sounds a lot more complicated-but-elementary when I write it out. Come to think of it--I should just @Persist the key value, which is smaller than the all the setting data used to construct the key. PS-- if you see something very wrong about this picture, please let me know! Daniel Jue On Nov 29, 2007 8:01 PM, Kalle Korhonen [EMAIL PROTECTED] wrote: Of course, nothing prevents one writing a semi-automatic workspace management layer on top of Seam that would take care of detecting and closing abandoned conversations (for example, along the lines I suggested on the Trails list). The Seam guys have carefully removed any dependencies to JSF. In practice, integrating Tap5 with Seam might be the fastest way of getting practical results for a conversational scope, and wouldn't solve only one but two problems at the same time (conversations and session-per-conversation), of course at the expense of tying the implementation more closely with Hibernate or at least JPA, but that's probably what the majority is using anyway. I'm sure the Seam guys would love to see Tapestry support for Seam. And btw, Wicket guys have already done this. Given that you Geoff are probably inclined to use J2EE container anyway, wouldn't it make sense to you to start looking at creating tapestry-seam integration project? It might be an interesting project to take on for me as well. Kalle On 11/28/07, Kalle Korhonen [EMAIL PROTECTED] wrote: I completely agree with Geoff that a good-enough generic support for conversations could make developing web applications much easier and it's one of the remaining big issues that web frameworks typically don't offer a solution for out-of-the-box. Seam's got a solution that works well for typical enterprise apps that may have high amount of interaction with the database but don't have a huge number of users. While Seam ignores the problem of closing abandoned conversations, it'll quickly lead to much higher memory consumption as open conversations generally occupy memory until explicitly closed or the session is expired. There's been various tries at solving the conversation support for Tapestry and we are planning on supporting conversation in Trails with a tighter memory management model for better scalability. I've written some notes on session-per-conversation at http://archive.trails.codehaus.org/users/[EMAIL PROTECTED]'s relevant for this discussion as well. For Tap5, you can of course come up with your own solution, but it'd be great if the framework had a generic support for conversations that would work well enough in the most common cases out-of-the-box and could be extended. Kalle On 11/28/07, Thiago HP [EMAIL PROTECTED] wrote: On 11/28/07, Francois Armand [EMAIL PROTECTED] wrote: I completely agree with your remarks, and it's a kind of pity that T5 is such in advance in so many areas, and in the same time have to deals by hand with that. Let's not forget that Tapestry 5 is still alpha and there are other areas needing work too, AJAX being one of the most anticipated ones. In addition, it has a very flexible architecture that allows developers (Howard, other T5 comitters or me or you) to implement any missing feature. ;) Thiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Is Persist(conversation) planned? Please?
Hi Kalle, I found this suggestion interesting, T5 already has Spring integration, which one will be easier for the user, Seam or Spring? A.C. Kalle Korhonen-2 wrote: JSF. In practice, integrating Tap5 with Seam might be the fastest way of getting practical results for a conversational scope, and wouldn't solve only one but two problems at the same time (conversations and session-per-conversation), of course at the expense of tying the -- View this message in context: http://www.nabble.com/T5%3A-Is-Persist%28%22conversation%22%29-planned---Please--tf4888105.html#a14042379 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Is Persist(conversation) planned? Please?
Kalle, I hadn't considered for a second that Tapestry could, or even should, be integrated with Seam, but it's a wild idea that just might make sense! Just had a look at the Wicket-Seam Integration code and at first blush it looks like Tapestry-Seam would be very doable. For anyone who's interested, have a look at the wicket-seam section in https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/ . I would really love to dig further into this, but I very much doubt I could find the time. Ideally it would be done by someone who already has a good handle on Seam. Anyone out there keen to take this on?? Does Tapestry have the equivalent of the wicket-stuff development area? Should it? http://wicketstuff.org/confluence/display/STUFFWEB/Home Cheers, Geoff On 30/11/2007, at 12:01 PM, Kalle Korhonen wrote: Of course, nothing prevents one writing a semi-automatic workspace management layer on top of Seam that would take care of detecting and closing abandoned conversations (for example, along the lines I suggested on the Trails list). The Seam guys have carefully removed any dependencies to JSF. In practice, integrating Tap5 with Seam might be the fastest way of getting practical results for a conversational scope, and wouldn't solve only one but two problems at the same time (conversations and session-per-conversation), of course at the expense of tying the implementation more closely with Hibernate or at least JPA, but that's probably what the majority is using anyway. I'm sure the Seam guys would love to see Tapestry support for Seam. And btw, Wicket guys have already done this. Given that you Geoff are probably inclined to use J2EE container anyway, wouldn't it make sense to you to start looking at creating tapestry-seam integration project? It might be an interesting project to take on for me as well. Kalle On 11/28/07, Kalle Korhonen [EMAIL PROTECTED] wrote: I completely agree with Geoff that a good-enough generic support for conversations could make developing web applications much easier and it's one of the remaining big issues that web frameworks typically don't offer a solution for out-of-the-box. Seam's got a solution that works well for typical enterprise apps that may have high amount of interaction with the database but don't have a huge number of users. While Seam ignores the problem of closing abandoned conversations, it'll quickly lead to much higher memory consumption as open conversations generally occupy memory until explicitly closed or the session is expired. There's been various tries at solving the conversation support for Tapestry and we are planning on supporting conversation in Trails with a tighter memory management model for better scalability. I've written some notes on session-per-conversation at http://archive.trails.codehaus.org/users/[EMAIL PROTECTED]'s relevant for this discussion as well. For Tap5, you can of course come up with your own solution, but it'd be great if the framework had a generic support for conversations that would work well enough in the most common cases out-of-the-box and could be extended. Kalle On 11/28/07, Thiago HP [EMAIL PROTECTED] wrote: On 11/28/07, Francois Armand [EMAIL PROTECTED] wrote: I completely agree with your remarks, and it's a kind of pity that T5 is such in advance in so many areas, and in the same time have to deals by hand with that. Let's not forget that Tapestry 5 is still alpha and there are other areas needing work too, AJAX being one of the most anticipated ones. In addition, it has a very flexible architecture that allows developers (Howard, other T5 comitters or me or you) to implement any missing feature. ;) Thiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Is Persist(conversation) planned? Please?
Of course, nothing prevents one writing a semi-automatic workspace management layer on top of Seam that would take care of detecting and closing abandoned conversations (for example, along the lines I suggested on the Trails list). The Seam guys have carefully removed any dependencies to JSF. In practice, integrating Tap5 with Seam might be the fastest way of getting practical results for a conversational scope, and wouldn't solve only one but two problems at the same time (conversations and session-per-conversation), of course at the expense of tying the implementation more closely with Hibernate or at least JPA, but that's probably what the majority is using anyway. I'm sure the Seam guys would love to see Tapestry support for Seam. And btw, Wicket guys have already done this. Given that you Geoff are probably inclined to use J2EE container anyway, wouldn't it make sense to you to start looking at creating tapestry-seam integration project? It might be an interesting project to take on for me as well. Kalle On 11/28/07, Kalle Korhonen [EMAIL PROTECTED] wrote: I completely agree with Geoff that a good-enough generic support for conversations could make developing web applications much easier and it's one of the remaining big issues that web frameworks typically don't offer a solution for out-of-the-box. Seam's got a solution that works well for typical enterprise apps that may have high amount of interaction with the database but don't have a huge number of users. While Seam ignores the problem of closing abandoned conversations, it'll quickly lead to much higher memory consumption as open conversations generally occupy memory until explicitly closed or the session is expired. There's been various tries at solving the conversation support for Tapestry and we are planning on supporting conversation in Trails with a tighter memory management model for better scalability. I've written some notes on session-per-conversation at http://archive.trails.codehaus.org/users/[EMAIL PROTECTED]'s relevant for this discussion as well. For Tap5, you can of course come up with your own solution, but it'd be great if the framework had a generic support for conversations that would work well enough in the most common cases out-of-the-box and could be extended. Kalle On 11/28/07, Thiago HP [EMAIL PROTECTED] wrote: On 11/28/07, Francois Armand [EMAIL PROTECTED] wrote: I completely agree with your remarks, and it's a kind of pity that T5 is such in advance in so many areas, and in the same time have to deals by hand with that. Let's not forget that Tapestry 5 is still alpha and there are other areas needing work too, AJAX being one of the most anticipated ones. In addition, it has a very flexible architecture that allows developers (Howard, other T5 comitters or me or you) to implement any missing feature. ;) Thiago
T5: Is Persist(conversation) planned? Please?
Hi, T5 has done some great work in handling common web problems with its fresh approach to navigation, but I'm very concerned that T5 will be swept aside by developers demanding frameworks that, at last, completely deal with the Back button, double-submit, etc, etc. It's ridiculous that we all keep hunting around to solve these issues, and I reckon we'll jump at any framework that does it for us. A classic case in point is session persistence. It so nearly works, but in fact it's dangerous. It doesn't even handle multiple windows and tabs safely (why? because they share the same HttpSession and therefore have concurrent access to the same session persisted objects). Over and over again, developers have to use a lot of brain- power to make it safe. Actually, I haven't seen anyone come up with a cookbook solution. Then, along comes JBoss Seam offering a solution - conversations. I believe that Seam can tag each window and tab with its own conversation id and persist its objects in the session tagged with conversation id. It can even tag windows within windows, or so I believe. They claim that conversations eliminates a whole bunch of bugs caused by back buttons, refresh buttons, double submits, multi- window browsing, post then redirects, 'these all vanish when you have conversations'.. (http://www.infoq.com/news/JBoss-SEAM-1.0-Gavin-interview ) So, could T5 introduce Persist(conversation) or something similar, and take a whole class of problems away for good? Please, please? If T5 doesn't offer a clear solution to each web problem then I fear people will be drawn to frameworks that do instead. And that would be a massive shame. Regards, Geoff
RE: T5: Is Persist(conversation) planned? Please?
hi geoff, i was thinking of implementing such a conversation or flow library in T5 myself and did some experiments I think a possible way of implementing such a feature is to define a conversation persistence strategy. Furthermore you need to enode the conversation id into the url (or create a hidden input field like seam or spring webflow). this can be done using the LinkFactory. on a conversation request a dispatcher will analyse the id and create a thread scoped service that will pull out the conversation specific data from the httpsession. g, kris Geoff Callender [EMAIL PROTECTED] 28.11.2007 13:06 Bitte antworten an Tapestry users users@tapestry.apache.org An Tapestry users users@tapestry.apache.org Kopie Thema T5: Is Persist(conversation) planned? Please? Hi, T5 has done some great work in handling common web problems with its fresh approach to navigation, but I'm very concerned that T5 will be swept aside by developers demanding frameworks that, at last, completely deal with the Back button, double-submit, etc, etc. It's ridiculous that we all keep hunting around to solve these issues, and I reckon we'll jump at any framework that does it for us. A classic case in point is session persistence. It so nearly works, but in fact it's dangerous. It doesn't even handle multiple windows and tabs safely (why? because they share the same HttpSession and therefore have concurrent access to the same session persisted objects). Over and over again, developers have to use a lot of brain- power to make it safe. Actually, I haven't seen anyone come up with a cookbook solution. Then, along comes JBoss Seam offering a solution - conversations. I believe that Seam can tag each window and tab with its own conversation id and persist its objects in the session tagged with conversation id. It can even tag windows within windows, or so I believe. They claim that conversations eliminates a whole bunch of bugs caused by back buttons, refresh buttons, double submits, multi- window browsing, post then redirects, 'these all vanish when you have conversations'.. ( http://www.infoq.com/news/JBoss-SEAM-1.0-Gavin-interview ) So, could T5 introduce Persist(conversation) or something similar, and take a whole class of problems away for good? Please, please? If T5 doesn't offer a clear solution to each web problem then I fear people will be drawn to frameworks that do instead. And that would be a massive shame. Regards, Geoff
Re: T5: Is Persist(conversation) planned? Please?
Geoff Callender wrote: Hi, Hello Geoff, [... common problem of web...] So, could T5 introduce Persist(conversation) or something similar, and take a whole class of problems away for good? Please, please? I completely agree with your remarks, and it's a kind of pity that T5 is such in advance in so many areas, and in the same time have to deals by hand with that. It was a time were Howard spoke of integrating Spring Webflow in T5, but I'm not sure it handle all the problem you raise, and I don't know if it's still in the TODO list. So I think that the best think to do is log a Jira entry for that, and make people vote for it :) -- Francois Armand Etudes Développements J2EE Groupe Linagora - http://www.linagora.com Tél.: +33 (0)1 58 18 68 28 --- InterLDAP - http://interldap.org FederID - http://www.federid.org/ Open Source identities management and federation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Is Persist(conversation) planned? Please?
On 11/28/07, Francois Armand [EMAIL PROTECTED] wrote: I completely agree with your remarks, and it's a kind of pity that T5 is such in advance in so many areas, and in the same time have to deals by hand with that. Let's not forget that Tapestry 5 is still alpha and there are other areas needing work too, AJAX being one of the most anticipated ones. In addition, it has a very flexible architecture that allows developers (Howard, other T5 comitters or me or you) to implement any missing feature. ;) Thiago
Re: T5: Is Persist(conversation) planned? Please?
I completely agree with Geoff that a good-enough generic support for conversations could make developing web applications much easier and it's one of the remaining big issues that web frameworks typically don't offer a solution for out-of-the-box. Seam's got a solution that works well for typical enterprise apps that may have high amount of interaction with the database but don't have a huge number of users. While Seam ignores the problem of closing abandoned conversations, it'll quickly lead to much higher memory consumption as open conversations generally occupy memory until explicitly closed or the session is expired. There's been various tries at solving the conversation support for Tapestry and we are planning on supporting conversation in Trails with a tighter memory management model for better scalability. I've written some notes on session-per-conversation at http://archive.trails.codehaus.org/users/[EMAIL PROTECTED]'s relevant for this discussion as well. For Tap5, you can of course come up with your own solution, but it'd be great if the framework had a generic support for conversations that would work well enough in the most common cases out-of-the-box and could be extended. Kalle On 11/28/07, Thiago HP [EMAIL PROTECTED] wrote: On 11/28/07, Francois Armand [EMAIL PROTECTED] wrote: I completely agree with your remarks, and it's a kind of pity that T5 is such in advance in so many areas, and in the same time have to deals by hand with that. Let's not forget that Tapestry 5 is still alpha and there are other areas needing work too, AJAX being one of the most anticipated ones. In addition, it has a very flexible architecture that allows developers (Howard, other T5 comitters or me or you) to implement any missing feature. ;) Thiago
