good idea. Do you mean requesting a page and cut
> it out or grabbing part of the DOM during same request. Just wondering... .
>
> -Ursprüngliche Nachricht-
> Von: Davor Hrg [mailto:[EMAIL PROTECTED]
> Gesendet: Mittwoch, 19. März 2008 10:42
> An: Tapestry user
Well, i believe if someone is aware of these issues, there's nothing
wrong with using
this solution - I've had some cases where data access is fast but data
processing
(in order to present) was quite complex, so this really helped.
For reference, another not-yet-mentioned problem of this kind of c
I agree that this is not something to take on lightly,
and data should be cached, and rendering left as is.
but besides caching this king of component is useful
for capturing output so it can be sent via email for example.
I like to keep most things stateless (only dependant on parameters),
so fro
:)
True. I definitely won't say that this will solve all cases 100%. But
for basic rendering.. this allows you to essentially set "expires" for
fragments of the page. And yes it caches all operations that go through
PageRenderSupport. And if I could take over the markupWriter properly,
I
I'm generally against these approached.
Cache the data, make it fast to access.
Let Tapestry do a full render every time.
You'll end up with confusing, unforseen consequences.
Rendering is increasingly a complex dance between components. That's
the power and the penalty of Tapestry. Component
thanks :)
It's 00:46 here, I'll try it out in the morning,
If I make it work I'll create a wiki page for it...
Davor Hrg
On Wed, Mar 19, 2008 at 12:38 AM, Fernando Padilla <[EMAIL PROTECTED]> wrote:
> here you go :)
>
> Should be able to drop these into your project.
>
> The Buffer.java is the
here you go :)
Should be able to drop these into your project.
The Buffer.java is the component ( so somewhere under components package
), and the BufferServices needs to go somewhere where Tapestry will not
enhance it, so I put it under the services package. ). :) Sorry, but
the "cacheKey/E
I'm interested in the one for T5 :)
if you are not allowed to share source,
maybe few hints how to make it
Davor Hrg
On Tue, Mar 18, 2008 at 7:22 PM, Fernando Padilla <[EMAIL PROTECTED]> wrote:
> We have a component that we call "Buffer" :) it takes a timeout,
> optional cachekey, and optional
I had done
http://andyhot.di.uoa.gr/tapfx/app?service=page/Cache
for T3 and T4 @ http://tapfx.sourceforge.net/
but it needed ehcache
Perhaps combine the two (esp. since there's no T5 version) and move to tacos?
On Tue, Mar 18, 2008 at 8:22 PM, Fernando Padilla <[EMAIL PROTECTED]> wrote:
> We hav
We have a component that we call "Buffer" :) it takes a timeout,
optional cachekey, and optional lastmodified (to tell you)
We have it for Tap4 and Tap5, if anyone really wants it, I bet I can
liberate it.. you would just have to change the cache hooks to use
whatever cache you want to use...
8 +0100
> >> Von: "Filip S. Adamsen" <[EMAIL PROTECTED]>
> >> An: Tapestry users
> >> Betreff: Re: AW: @Cached and caching in general
> >
> >> A factor 100?? C'mon. If, and I stress IF, your application would
> >>
4:28 +0100
Von: "Filip S. Adamsen" <[EMAIL PROTECTED]>
An: Tapestry users
Betreff: Re: AW: @Cached and caching in general
A factor 100?? C'mon. If, and I stress IF, your application would
benefit that much from this, fine. But Tapestry 5 applications in
general would - I
Ok...let's say factor 10 (unless you have many loops inside of loops inside of
loops that use queries on large tables).
Original-Nachricht
> Datum: Tue, 18 Mar 2008 18:14:28 +0100
> Von: "Filip S. Adamsen" <[EMAIL PROTECTED]>
> An: Tapestry users
A factor 100?? C'mon. If, and I stress IF, your application would
benefit that much from this, fine. But Tapestry 5 applications in
general would - I guarantee you - not see such an improvement.
-Filip
On 2008-03-18 18:07, Tobias Marx wrote:
My theory is that such a disk-caching behaviour coul
14 matches
Mail list logo
