You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Thiago HP <th...@gmail.com> on 2007/11/29 01:00:18 UTC
Re: T5: Is Persist("conversation") planned? Please?
On 11/28/07, Francois Armand <fa...@linagora.com> 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?
Posted by Kalle Korhonen <ka...@gmail.com>.
On 11/30/07, Geoff Callender <ge...@gmail.com> 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 <ka...@gmail.com> 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/7281ca710709272055s71dd7375m797a3cbf88535334@mail.gmail.comthat'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 <th...@gmail.com> wrote:
> >>>
> >>> On 11/28/07, Francois Armand <fa...@linagora.com> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: T5: Is Persist("conversation") planned? Please?
Posted by Geoff Callender <ge...@gmail.com>.
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 <ka...@gmail.com> 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/7281ca710709272055s71dd7375m797a3cbf88535334@mail.gmail.comthat'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 <th...@gmail.com> wrote:
>>>
>>> On 11/28/07, Francois Armand <fa...@linagora.com> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Is Persist("conversation") planned? Please?
Posted by Daniel Jue <te...@gmail.com>.
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
<ch...@gmail.com> 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 <ka...@gmail.com>
> > 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 <ka...@gmail.com> 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/7281ca710709272055s71dd7375m797a3cbf88535334@mail.gmail.comthat'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 <th...@gmail.com> wrote:
> >>>>
> >>>> On 11/28/07, Francois Armand <fa...@linagora.com> 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: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Is Persist("conversation") planned? Please?
Posted by Christian Edward Gruber <ch...@gmail.com>.
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 <ka...@gmail.com>
> 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 <ka...@gmail.com> 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/7281ca710709272055s71dd7375m797a3cbf88535334@mail.gmail.comthat'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 <th...@gmail.com> wrote:
>>>>
>>>> On 11/28/07, Francois Armand <fa...@linagora.com> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Is Persist("conversation") planned? Please?
Posted by Daniel Jue <te...@gmail.com>.
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 <ka...@gmail.com> 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 <ka...@gmail.com> 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/7281ca710709272055s71dd7375m797a3cbf88535334@mail.gmail.comthat'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 <th...@gmail.com> wrote:
> > >
> > > On 11/28/07, Francois Armand <fa...@linagora.com> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Is Persist("conversation") planned? Please?
Posted by Kalle Korhonen <ka...@gmail.com>.
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 <an...@yahoo.com.hk> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: T5: Is Persist("conversation") planned? Please?
Posted by Angelo Chen <an...@yahoo.com.hk>.
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Is Persist("conversation") planned? Please?
Posted by Kalle Korhonen <ka...@gmail.com>.
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 <ka...@gmail.com> 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/7281ca710709272055s71dd7375m797a3cbf88535334@mail.gmail.comthat'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 <th...@gmail.com> wrote:
> >
> > On 11/28/07, Francois Armand <fa...@linagora.com> 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?
Posted by Kalle Korhonen <ka...@gmail.com>.
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/7281ca710709272055s71dd7375m797a3cbf88535334@mail.gmail.comthat'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 <th...@gmail.com> wrote:
>
> On 11/28/07, Francois Armand <fa...@linagora.com> 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
>