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 Tap
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:
> I
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
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). Ins
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
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),
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 conversation
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 pr
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 e
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 are
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 adva
ific data from the httpsession.
g,
kris
Geoff Callender <[EMAIL PROTECTED]>
28.11.2007 13:06
Bitte antworten an
"Tapestry users"
An
Tapestry users
Kopie
Thema
T5: Is Persist("conversation") planned? Please?
Hi,
T5 has done some great work in handling common
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
13 matches
Mail list logo
