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#a13901135
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]