Should I be concerned that the numbers in the following URLs jump so much?
This is on a page signed in as an admin, where I do have some callback links
that are stateful.
On one page view, here is an admin link:
http://www.texashuntfish.dev/thf/app?wicket:interface=:12492:list:posts:0:postSummary:delete::ILinkListener
I refresh (no other page views in between), and it changes to:
http://www.texashuntfish.dev/thf/app?wicket:interface=:13999:list:posts:0:postSummary:delete::ILinkListener
That's an increase of 1500 in a single page view... I am concerned that
somehow this means that I have 1500 components going into memory for a
single page? Is that number changing so drastically something to be alarmed
about?
Thank you!
Jeremy
On 5/3/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> Thanks to everyone for their help - I'm starting right away to convert
> everything to detachable models for all domain objects that are loaded
into
> components...
If you're only working with stateless pages, you don't detachable
models as those pages won't be stored to start with. But if you want
to reuse the models and components in stateful pages, it is better to
have that.
> Eelco, I am curious about your statement "when you have no callbacks,
you're
> page will be stateless and not kept in memory"... Most of my pages have
no
> callbacks (by callback, I'm assuming that you mean a link that would
have
> reference to wicket components in the URL, meaning that it is storing
the
> state of that component so that it can further interact with it).
Yep. Normal Links, Forms, ajax requests etc.
> I have
> taken great care to control the URLs of the application, so almost every
> page has only components that have standard URLs, with no references to
any
> components, etc. The forms will obviously have a call back, and certain
> links (particularly if you are signed in as an administrator - a lot of
> links appear to edit and delete content that are all direct callbacks
with
> obviously no direct URL encoding / decoding so that you can not use them
> outside of your session).
Not sure what you're getting at...
> So, how do I know if it's storing the pages in memory? Is there
something I
> can do to tell it not to?
Yeah, you can give provide a HINT that they shouldn't be stored (that
they are stateless) by overriding getStatelessHint on the components
you put on the page. Note that if there is just one stateful component
on the page, that'll trigger the page to be marked as stateful UNLESS
you explicitly mark the page itself stateless (which is a bit cheaper
by the way, as it won't iterate over it's children to find out whether
it is stateless).
The method where this all happens is Page#isPageStateless.
Also, if you want to keep track of when user sessions are created,
create a custom session store by overriding newSessionStore on
Application and let your custom store extend HttpSessionStore or
SecondLevelCacheSessionStore and then override onBind which will be
called when (new) sessions are bound to the HttpSession.
Eelco
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
