if you dont mind putting this into a wrapper there is a containertransformer or something like that.
-igor On Sat, Mar 28, 2009 at 1:13 AM, Daniel Frisk <[email protected]> wrote: > Great ideas! I think I will try to implement it is a WebComponent decorator > that can wrap a component and add the caching. I'll let you know if it works > out for me. > > // Daniel > jalbum.net > > > > On 2009-03-27, at 20:40, Matej Knopp wrote: > >> You have to be really brave to use IComponentSource :-) >> >> It's almost never a good idea anyway. It makes sense if you have >> container with big amount of small component and you can restore the >> whole hierarchy from e.g. an entity Id. >> >> but it was last time used with Wicket 1.3. There's not guarantee it will >> work... >> >> -Matej >> >> On Fri, Mar 27, 2009 at 8:13 PM, Igor Vaynberg <[email protected]> >> wrote: >>> >>> ive never had to do this, but maybe something like this will work :) >>> >>> class myheavypanel implements icomponentsource { >>> private String cache; >>> >>> public Component restoreComponent(String id) { >>> if (cache==null) { >>> return this; >>> } else { >>> return new label(id, cache).setescapemarkup(false); >>> } >>> } >>> >>> public myheavypanel() { >>> ..... >>> add(new abstracttransformbehavor() { >>> public abstract CharSequence transform(final Component >>> component, final CharSequence output) { >>> myheavypanel.this.cache=output; >>> return output; >>> }}); >>> } >>> >>> } >>> >>> >>> its kinda hacky but might work :) >>> >>> -igor >>> >>> On Fri, Mar 27, 2009 at 11:50 AM, 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] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> 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] >> > > > --------------------------------------------------------------------- > 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]
