Even supposing that you don't already have some other cache engine built into your app somewhere, couldn't you build a simple caching model class much easier than caching rendered HTML. To cache the rendered HTML you must:
1 - on request one, create the component, render it, cache the rendered HTML, output it 2 - on request two, not create the component, find the rendered HTML, use a label or something to render the html instead Perhaps you could easily just create a caching model that wraps another model and uses ehcache. It would be fairly simple: See http://ehcache.sourceforge.net/samples.html (pseudo-code) class CachingModel<T> extends LoadableDetachableModel<T> { final String cacheKey; final IModel<T> model; public CachingModel(String cacheKey, IModel<T> model) { this.model = model; this.cacheKey = cacheKey; } @Override public T load() { Cache cache = CacheManager.getInstance().getCache(getClass().getSimpleName()); Element elem = cache.getElement(this.cacheKey); if (elem == null) { elem = new Element(this.cacheKey, this.model.getObject()); cache.put(elem); } return elem.getObjectValue(); } @Override public void onDetach() { super.onDetach(); this.model.detach(); } } -- Jeremy Thomerson http://www.wickettraining.com On Fri, Mar 27, 2009 at 1:50 PM, Daniel Frisk <[email protected]> wrote: > 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 < >> [email protected]> 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: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
