You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Icy <ic...@astute.de> on 2007/11/22 10:10:09 UTC
How to instanciate panels best?
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#a13893312
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How to instanciate panels best?
Posted by Jonathan Locke <jo...@gmail.com>.
here's a component solution to panel caching (with a couple of caveats):
http://web.mac.com/jonathan.locke/iWeb/JonathanLocke/Blog/6DDE5C7F-55B4-44FC-965C-AB87F236F78C.html
i don't think it would be a great idea to use this component much, but
there are definitely places where it might be very convenient if you have
high traffic and know what you're doing.
Jonathan Locke wrote:
>
>
> 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#a13902869
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How to instanciate panels best?
Posted by Jonathan Locke <jo...@gmail.com>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How to instanciate panels best?
Posted by Jonathan Locke <jo...@gmail.com>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How to instanciate panels best?
Posted by Jonathan Locke <jo...@gmail.com>.
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#a13900949
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How to instanciate panels best?
Posted by Icy <ic...@astute.de>.
Al Maw-2 wrote:
>
> Icy wrote:
>> *** What is the "best practise" to not instanciate "page aggregating
>> panels"
>> all the time? ***
>
> This isn't really a Wicket question.
>
> Your page is slow because doing database/remote operations is slow. It
> has nothing to do with creating Panels, but everything to do with the
> database access you're doing in the constructor of those Panels.
>
> You need to break those operations out into a service layer that can
> cache the results, then use that service layer in your constructor.
>
> Regards,
>
> Al
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
Dear Al,
Thanks for your help. If I interpret your answer correctly, this means that
the way my page is composed and the panels are instanciated is "the Wicket
way", I mean, correct.
Ok, what I could do then, is creating Spring managed singleton beans (I work
with a Wicket/Spring/Hibernate environment) - or at least one - that gather
the data for me, and let my panels request the data from the Spring bean. So
this somehow means I do the caching on my own, to fill the panels
efficiently, but if this is how it has to be done using Wicket, I will go
that way without thinking I am doing something unelegant.
Many thanks,
Icy
--
View this message in context: http://www.nabble.com/How-to-instanciate-panels-best--tf4855189.html#a13895934
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How to instanciate panels best?
Posted by Icy <ic...@astute.de>.
Dear Eelco and Jonathan,
Thanks for all your effort put into clarifying this issue.
I will have a look at the caching approach, and for sure see how I can reuse
the panel data. And YourKit really looks like a great profiling tool, thanks
for the tip, didn't know it before! :)
I have an idea how I could optimize the Panel creation based on your
suggestions, please tell me if this makes sense: I could store data like
UserData, Friendslist, etc. to the user session, and attach it to the
Components of the Panel using a PropertyModel. Then, data is only stored one
time in the session. Does this work? What's the maximum size of the user
session?
Kind regards,
Bernd
Eelco Hillenius wrote:
>
>> MyPanel.java
>> public class MyPanel extends Panel {
>> public MyPanel() {
>> // THIS PANEL IS RECONSTRUCTED ON EACH MyPage REQUEST
>> // BECAUSE MyPageTemplate DOES A new MyPanel...
>> }
>> }
>>
>> What could I do to use the old panel again?
>
> Like Al hinted, you should not try to use the old panel again, but
> instead focus on more fruitful forms of optimization. The construction
> of Wicket components isn't very expensive in itself. What typically
> makes it expensive is the data you expose through it, either using
> models or directly. So what you should do is cache/ reuse the data
> where you can, so that you avoid database round trips and other
> expensive processing.
>
> Often, the best thing to do when it comes to optimizing is to use a
> profiler (YourKit for instance). Optimizing without using a profiler
> to determine what the bottlenecks probably means you're optimizing the
> wrong things.
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/How-to-instanciate-panels-best--tf4855189.html#a13909086
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How to instanciate panels best?
Posted by Eelco Hillenius <ee...@gmail.com>.
> MyPanel.java
> public class MyPanel extends Panel {
> public MyPanel() {
> // THIS PANEL IS RECONSTRUCTED ON EACH MyPage REQUEST
> // BECAUSE MyPageTemplate DOES A new MyPanel...
> }
> }
>
> What could I do to use the old panel again?
Like Al hinted, you should not try to use the old panel again, but
instead focus on more fruitful forms of optimization. The construction
of Wicket components isn't very expensive in itself. What typically
makes it expensive is the data you expose through it, either using
models or directly. So what you should do is cache/ reuse the data
where you can, so that you avoid database round trips and other
expensive processing.
Often, the best thing to do when it comes to optimizing is to use a
profiler (YourKit for instance). Optimizing without using a profiler
to determine what the bottlenecks probably means you're optimizing the
wrong things.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How to instanciate panels best?
Posted by Icy <ic...@astute.de>.
Hello all,
I try to explain my question using sourcecode ;)
Imagine:
MyTemplate.java
public abstract class MyTemplate extends WebPage {
public MyTemplate() {
add(new MyPanel("myPanel"));
}
}
MyTemplate.html
<body>
<wicket:child/>
</body>
MyPage.java (html is trivial, using wicket:extend)
public class MyPage extends MyTemplate {
...
}
MyPanel.java
public class MyPanel extends Panel {
public MyPanel() {
// THIS PANEL IS RECONSTRUCTED ON EACH MyPage REQUEST
// BECAUSE MyPageTemplate DOES A new MyPanel...
}
}
What could I do to use the old panel again? Do I really have to care about
the panel object reference by myself, i.e. store is to the user session,
check if it is there, if yes then retrieve, if not the do a new, etc.? I
don't have to, do I? The Panel is in the wicket session anyway, and the user
session would grow too much, leasing to the StackOverflowError I already had
...
I hope you can help me, thanks in advance :)
Kind regards,
Bernd
Icy wrote:
>
>
>
> Al Maw-2 wrote:
>>
>> Icy wrote:
>>> *** What is the "best practise" to not instanciate "page aggregating
>>> panels"
>>> all the time? ***
>>
>> This isn't really a Wicket question.
>>
>> Your page is slow because doing database/remote operations is slow. It
>> has nothing to do with creating Panels, but everything to do with the
>> database access you're doing in the constructor of those Panels.
>>
>> You need to break those operations out into a service layer that can
>> cache the results, then use that service layer in your constructor.
>>
>> Regards,
>>
>> Al
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> Heyho again, Al, and all,
>
> as with Spring it's not that easy to do what I wanted, because singleton
> beans are instanciated only once for ALL users, and prototype beans are
> instanciated on every request, which is too often, the natural target for
> storing sinlgeton references to objects for a user is the SESSION again...
> so I tried this.
>
> First question: I just wanted to put a wicket stuff GMap2 instance into
> the session, and got a java.lang.StackOverflowError. Is it possible to
> increase the stack size?
>
> Second question: Even if this works to construct GMap, etc. only once when
> the session is created, and add these components to a Panel on request,
> then still I have a common problem understanding the following:
>
> The special cool thing about Wicket is that components keep their state.
> If I have to instanciate all Panels again each time a page is requested,
> they for sure always loose their state - they are new. If I put everything
> in the session, to keep the state manually, then it will probably work,
> but that's old fashioned Web programming ;) Doesn't Wicket offer me the
> possibility to e.g. let a user scroll around in the Google Map Panel, and
> the scrolling position always remains the same on each page request? What
> about the cool Wicket Model approach, the Desktop App programming
> experience? What do I have to do to maintain Panels state?
>
> Please, explain this to me, it's a very very basic question for me, to
> understand the "magic" of the Wicket approach.
>
> Kind regards,
> Icy
>
>
>
>
--
View this message in context: http://www.nabble.com/How-to-instanciate-panels-best--tf4855189.html#a13900134
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How to instanciate panels best?
Posted by Icy <ic...@astute.de>.
Al Maw-2 wrote:
>
> Icy wrote:
>> *** What is the "best practise" to not instanciate "page aggregating
>> panels"
>> all the time? ***
>
> This isn't really a Wicket question.
>
> Your page is slow because doing database/remote operations is slow. It
> has nothing to do with creating Panels, but everything to do with the
> database access you're doing in the constructor of those Panels.
>
> You need to break those operations out into a service layer that can
> cache the results, then use that service layer in your constructor.
>
> Regards,
>
> Al
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
Heyho again, Al, and all,
as with Spring it's not that easy to do what I wanted, because singleton
beans are instanciated only once for ALL users, and prototype beans are
instanciated on every request, which is too often, the natural target for
storing sinlgeton references to objects for a user is the SESSION again...
so I tried this.
First question: I just wanted to put a wicket stuff GMap2 instance into the
session, and got a java.lang.StackOverflowError. Is it possible to increase
the stack size?
Second question: Even if this works to construct GMap, etc. only once when
the session is created, and add these components to a Panel on request, then
still I have a common problem understanding the following:
The special cool thing about Wicket is that components keep their state. If
I have to instanciate all Panels again each time a page is requested, they
for sure always loose their state - they are new. If I put everything in the
session, to keep the state manually, then it will probably work, but that's
old fashioned Web programming ;) Doesn't Wicket offer me the possibility to
e.g. let a user scroll around in the Google Map Panel, and the scrolling
position always remains the same on each page request? What about the cool
Wicket Model approach, the Desktop App programming experience? What do I
have to do to maintain Panels state?
Please, explain this to me, it's a very very basic question for me, to
understand the "magic" of the Wicket approach.
Kind regards,
Icy
--
View this message in context: http://www.nabble.com/How-to-instanciate-panels-best--tf4855189.html#a13899931
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How to instanciate panels best?
Posted by Al Maw <al...@gmail.com>.
Icy wrote:
> *** What is the "best practise" to not instanciate "page aggregating panels"
> all the time? ***
This isn't really a Wicket question.
Your page is slow because doing database/remote operations is slow. It
has nothing to do with creating Panels, but everything to do with the
database access you're doing in the constructor of those Panels.
You need to break those operations out into a service layer that can
cache the results, then use that service layer in your constructor.
Regards,
Al
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org