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
--
Von: Davor Hrg [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 19. März 2008 10:42
An: Tapestry users
Betreff: Re: AW: @Cached and caching in general
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 compon
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
> >>
-Nachricht
> Datum: Tue, 18 Mar 2008 18:22:01 +0100
> Von: "Martin Kersten" <[EMAIL PROTECTED]>
> An: "Tapestry users"
> Betreff: AW: @Cached and caching in general
> You might want to know what tapestry does with your templates.
> Tapestry read
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
Martin (Kersten)
-Ursprüngliche Nachricht-
Von: Tobias Marx [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 18. März 2008 18:15
An: Tapestry users
Betreff: AW: @Cached and caching in general
> The problem is context I guess. Usally your component depends on lots
> of stuff. Para
ity and
> everything that avoids template parsing would increase the speed a lot.
> >
> >
> > Original-Nachricht
> >> Datum: Tue, 18 Mar 2008 18:01:40 +0100
> >> Von: "Martin Kersten" <[EMAIL PROTECTED]>
> >> An: "Tapestry users"
> The problem is context I guess. Usally your component depends on lots
> of stuff. Parameters, URL, Services, Page-state, component state,
> HTTP-Parameters and so on.
Yes...but it must be possible somehow as some PHP template engines also do it.
Isn't there already some mechanism in the inte
08 18:01:40 +0100
Von: "Martin Kersten" <[EMAIL PROTECTED]>
An: "Tapestry users"
Betreff: AW: @Cached and caching in general
@Chached is only used during a single page rendering cycle. It would not
apply to your situation. (as far as I know)
Source:
http://sqllyw.wordpr
.
Original-Nachricht
> Datum: Tue, 18 Mar 2008 18:01:40 +0100
> Von: "Martin Kersten" <[EMAIL PROTECTED]>
> An: "Tapestry users"
> Betreff: AW: @Cached and caching in general
> @Chached is only used during a single page rendering cycle. It would not
>
The problem is context I guess. Usally your component depends on lots
of stuff. Parameters, URL, Services, Page-state, component state,
HTTP-Parameters and so on. Providing such a low-level cache might
sound reasonable but remembering my own requirements lots of days back
(2001) the cache depende
@Chached is only used during a single page rendering cycle. It would not
apply to your situation. (as far as I know)
Source:
http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/
Your scenario would be implementable using your own component.
The component would represent a fragmen
21 matches
Mail list logo
