of course, this only caches the rendering of a component within a session.
and it would only work for components with a fixed path. i'm not sure
what it would mean to cache the results of a component globally.
with a fair amount of magic, you might be able to create a CachingPanel
component in the existing wicket. you'd take over the rendering process,
and render self based on class identity and interval. that would certainly
be a less invasive approach.
it may be that all these things are best left out of wicket, but it can't
hurt to
think about it a bit.
Jonathan Locke wrote:
>
>
> actually one way to solve this that would not involve changing wicket's
> session
> model would be to do what that thread suggested in terms of caching:
>
> /**
> * @return Duration between renders of this page or null to always render
> *
> */
> protected Duration getRenderInterval()
> {
> return Duration.ONE_MINUTE;
> }
>
> just put that method on Component instead of Page. the rendered markup
> would naively be cached in Component along with the time the component
> was last rendered, but the better place to do it would be in Session,
> keyed
> using the Component's path and time of last render. The cache in Session
> would only need to be checked for Components that override
> getRenderInterval().
> can someone remind me why we haven't done this? I can't even open the
> Page.java file on my Mac without Eclipse crashing, thanks to Apple.
>
>
> Jonathan Locke wrote:
>>
>>
>> session and application scope components are not supported in wicket up
>> to 1.3
>> (they will not work).
>>
>> this idea is really a request for more "static" components, like this
>> discussion of "static" pages:
>>
>>
>> http://www.nabble.com/Serving-Static-Pages-with-Wicket-tf3572749.html#a9995177
>>
>> i'm not sure if this idea is really possible or desirable to do this, but
>> it would,
>> as you point out, have efficiency upsides for certain kinds of web sites.
>> it
>> might be interesting to at least think about it some.
>>
>>
>> Icy wrote:
>>>
>>> Dear Wicket Team,
>>>
>>> First of all, let me say that Wicket is the best thing in Java Web
>>> development today! It really brings Java back to be a first choice when
>>> creating Web applications. Thanks for your development efforts :)
>>>
>>> I have a question regarding the instanciation of panels of which I have
>>> a huge number placed at top, bottom , left side and right side of a web
>>> site, and that should be shown again on any page of the side. This is a
>>> very common design I guess. I was browsing the documentation and the
>>> mail archive, but didn't really find a solution concerning the
>>> instanciation.
>>>
>>> This is the scenario:
>>> - I have a template page, that all other pages I create are extending.
>>> - This template page defines a number of panels (menu at the top,
>>> statistics and pictures at the left side, dynamic messages at the right
>>> side, ...), and for sure an area for the main page content using
>>> "wicket:child" approach.
>>> - The panels read data from the internet, and from a database, but their
>>> content does not change very often. Consider e.g. showing user
>>> statistics of how many messages he/she posted. This does only change
>>> when really a new message was posted.
>>>
>>> The problem:
>>> - Whenever a page is requested, the template page instantiates all
>>> panels using "add(new Panel("nameX"))". The panels do again read data
>>> from the internet, and from the database.
>>>
>>> This is not very fast, and it appears to me that the processing power
>>> and memory consumption for this might be high. Imagine thousands of
>>> users using the web site.
>>>
>>> I guess the approach I have chosen is not the best solution. The pages
>>> have models behind any way, so they know their data, they don't have to
>>> be reconstructed all the time. I have this behaviour e.g. when I submit
>>> a form, and no new target is given - the page is reconstructed without
>>> instanciating all panels again, it just renders all panels with the data
>>> coming from the models behind.
>>>
>>> *** What is the "best practise" to not instanciate "page aggregating
>>> panels" all the time? ***
>>>
>>> I had the following ideas:
>>>
>>> - Using the user session to store my page object references to check if
>>> a panel is already instanciated and then just use the reference instead
>>> of doing a new?
>>> - Using some mechanism to get a panel reference from the wicket session,
>>> where the page and models are stored anyway?
>>>
>>> -> Both approaches require unelegant "manual work", for which I think
>>> Wicket is offering something, as one of the main aspects of the Wicket
>>> framework is page management.
>>>
>>> - Using Spring to manage the Panels?
>>>
>>> -> Is this wanted from the Wicket design point of view? And does it
>>> really work?
>>>
>>> Many thanks in advance for your help. Maybe I really missed it and this
>>> very common problem is already explained somewhere.
>>>
>>> Kind regards
>>> Icy
>>>
>>>
>>>
>>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/How-to-instanciate-panels-best--tf4855189.html#a13901466
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
