caching every method by default is definitely too error prone,
and unexpected for most people.
On Tue, Mar 25, 2008 at 3:23 PM, Francois Armand <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Yes, you are right. But loops are usually inside of components and pages
> contain those compo
[EMAIL PROTECTED] wrote:
Yes, you are right. But loops are usually inside of components and pages contain those
componentsbut all methods in the page itself could be @Cache methods in my opinion if
you do a "component based approach" and always package logical widgets into a
component.
-Nachricht
> Datum: Tue, 25 Mar 2008 13:33:19 +0100
> Von: Francois Armand <[EMAIL PROTECTED]>
> An: Tapestry users
> Betreff: Re: @Cached and caching in general
> Tobias Marx wrote:
> > Wouldn't it be useful to make the @Cache annotation the default
>
Tobias Marx wrote:
Wouldn't it be useful to make the @Cache annotation the default annotation
for all methods?
I can not imagine a case where it would make sense that during the rendering of
a page returns different results...
Just an example : you are in a loop (or grid or a beaneditor any
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
ation. Since you have a fallback solution at hand (cron-jobs +
> > > disk fragments) you are at the safe side. But I am in doupt if you
> > > really need the markup being cached. Caching the database results
> > > and recreate markup sounds more reasonable. You might save you lot
--
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
mpliest solution first. So database queries without any caches.
> >> > Once you see any problems (performance is below required) just go for
> >> > optimization. Since you have a fallback solution at hand (cron-jobs +
> >> > disk fragments) you are at the sa
ase results
> and recreate markup sounds more reasonable. You might save you lots
> of seeking time.
>
> But you always know: Only the code / application will tell you!
>
>
> Cheers,
>
> Martin (Kersten)
>
> -----Ursprüngliche Nachricht-
> Von: Tobias
sounds more reasonable. You might save you lots
> > of seeking time.
> >
> > But you always know: Only the code / application will tell you!
> >
> >
> > Cheers,
> >
> > Martin (Kersten)
> >
> > -Ursprüngliche Nachricht-
&
would make sense that during the rendering
> of a page returns different results...
>
> Original-Nachricht
> > Datum: Tue, 18 Mar 2008 11:53:09 -0500
> > Von: "Adam Zimowski" <[EMAIL PROTECTED]>
>
> > An: "Tapestry users&q
rt your application. As always use
> >> > the simpliest solution first. So database queries without any caches.
> >> > Once you see any problems (performance is below required) just go for
> >> > optimization. Since you have a fallback solution at hand (cron-job
ve you lots
> of seeking time.
>
> But you always know: Only the code / application will tell you!
>
>
> Cheers,
>
> Martin (Kersten)
>
> -Ursprüngliche Nachricht-
> Von: Tobias Marx [mailto:[EMAIL PROTECTED]
> Gesendet: Dienstag, 18. März 2008 17:45
hed. Caching the database results
> > and recreate markup sounds more reasonable. You might save you lots
> > of seeking time.
> >
> > But you always know: Only the code / application will tell you!
> >
> >
> > Cheers,
> >
> > Martin (Kersten)
> >
will tell you!
> >
> >
> > Cheers,
> >
> > Martin (Kersten)
> >
> > -Ursprüngliche Nachricht-
> > Von: Tobias Marx [mailto:[EMAIL PROTECTED]
> > Gesendet: Dienstag, 18. März 2008 17:45
> > An: Tapestry users
> > Betr
Nachricht-
Von: Tobias Marx [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 18. März 2008 17:45
An: Tapestry users
Betreff: @Cached and caching in general
I have not used T5 yet, but would @Cached use the file system for caching HTML
fragments similiar to caching mechanisms in some php framewor
.
Mimic what is done currently, but perhaps schedule refreshes with Quartz and
keep it within the same app.
Jonathan
> -Original Message-
> From: Tobias Marx [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 18, 2008 1:35 PM
> To: Tapestry users
> Subject: AW: @Cached and cac
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
ginal-Nachricht
Datum: Tue, 18 Mar 2008 11:53:09 -0500
Von: "Adam Zimowski" <[EMAIL PROTECTED]>
An: "Tapestry users"
Betreff: Re: @Cached and caching in general
@Cache works on per request basis, so that anything you return from a
method which has @Cache annotatio
.
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
>
needed. But as far as I know Tapestry and its agility, all
you need
-Ursprüngliche Nachricht-
Von: Tobias Marx [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 18. März 2008 17:58
An: Tapestry users
Betreff: Re: @Cached and caching in general
Ok. Thanks...this is what I wanted to know.
What
2008 17:45
An: Tapestry users
Betreff: @Cached and caching in general
I have not used T5 yet, but would @Cached use the file system for caching HTML
fragments similiar to caching mechanisms in some php frameworks?
Or is this a pure memory-based cache?
I am thinking about migrating an old PHP
00
> Von: "Adam Zimowski" <[EMAIL PROTECTED]>
> An: "Tapestry users"
> Betreff: Re: @Cached and caching in general
> @Cache works on per request basis, so that anything you return from a
> method which has @Cache annotation will get actually "built"
y hour it would re-generate/refresh its output and this way save lots of
performance.
Original-Nachricht
> Datum: Tue, 18 Mar 2008 17:52:11 +0100
> Von: "Davor Hrg" <[EMAIL PROTECTED]>
> An: "Tapestry users"
> Betreff: Re: @Cached and
@Cache works on per request basis, so that anything you return from a
method which has @Cache annotation will get actually "built" or
"retrieved" only once - but only once per http request. So if you're
building an expensive HTML fragment:
@Cached
public String buildExpensiveHtmlFragment() {
//.
@Cached is an annotation
that caches method call result per request.
so while page is rendering if multiple pieces of template
require that property it gets called only once...
Davor Hrg
On Tue, Mar 18, 2008 at 5:44 PM, Tobias Marx <[EMAIL PROTECTED]> wrote:
> I have not used T5 yet, but would @C
I have not used T5 yet, but would @Cached use the file system for caching HTML
fragments similiar to caching mechanisms in some php frameworks?
Or is this a pure memory-based cache?
I am thinking about migrating an old PHP application to T5 - it has really a
lot of traffic and any users are log
33 matches
Mail list logo
