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 <igor.vaynb...@gmail.com> 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 <dan...@jalbum.net> 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 <
>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
