In our case it's not really that the rendering itself is taking to
long, it is getting the data from the model (database) so your advice
is in some sense correct. Restructuring the code so that we can
efficently cache the model is a lot of work and I would prefer to
somehow cache the rendered html.
So if we presume that I actually know what I am doing, any ideas how
it can be done?
// Daniel
On 2009-03-27, at 19:23, Jeremy Thomerson wrote:
Don't share component instances across requests / especially sessions.
Don't prematurely optimize.
Cache your model and test the rendering. If it really is taking too
long,
figure out why and worry about it then.
--
Jeremy Thomerson
http://www.wickettraining.com
On Fri, Mar 27, 2009 at 1:12 PM, Martin Grotzke <
martin.grot...@javakaffee.de> wrote:
Hi,
I also thought about s.th. like this because we'll have very complex
component graphs that have to be composed dynamically based on the
language of the user and ~3 other things. I thought about caching
complete component instances, but didn't come so far that I thought
about how this could be integrated into wicket - perhaps dead
simple via
some
_cacheService.getReallyComplexComponentCached( "complexComponent",
userInfo )
I don't know how cheap exactly rendering of our complex component
structure will be, but if this would take more than say 10 millis we
would also try to cache already rendered markup.
Cheers,
Martin
On Fri, 2009-03-27 at 16:49 +0100, Daniel Frisk wrote:
I have a situation where I have some panels which I want to render
say
at most once a minute and during that period they should be
"static".
I tried a few approches which hasn't really worked out for me so I
wanted to know if somebody has created such a thing or how this
could
be done. Ideas are also welcome...
// Daniel Frisk
jalbum.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
