we could use more complete docs on this issue and surely a FAQ entry when i can get to it.
in the meantime, it sounds to me like you may still be thinking in terms of other frameworks. perhaps tapestry? you need to try to unlearn that stuff to some degree. wicket is not a version of tapestry or any other framework. its design goals and implementation are quite different.
in general, pages and components in wicket are reused only when you implicitly reuse them in your java code. if you create a PageLink, you'll (most likely) create a new Page object each time that link is clicked. but if a link is an anonymous Link subclass, the page will remain unchanged and will be reused implicitly during rendering. spend some time staring at the linkomatic and navomatic examples and you'll come to understand. basically, if a new page isn't set somehow, the original page is re-rendered.
this kind of page rendering reuse typically happens when pages reference themselves via self-links or form submits or the like. when this occurs, there may be multiple renderings of the same page object cached in the client's browser. when pages have self-referential links which cause structural modifications to their model, there is the potential for stale markup issues. wicket detects this if you tell it when the model has changed. there is a good example of this is in the user's guide (which is very out of date now) and the library application. when you delete a row in the library application, the delete link is implemented like this:
listItem.add(listItem.removeLink("remove"));which looks very simple. but a lot of logic is hidden by this. first, removeLink is implemented like this:
public final Link removeLink(final String componentName)
{
return new Link(componentName)
{
public void linkClicked()
{
// Remove listItem and invalidate listView
listView.getList().remove(index);
listView.invalidateModel();
}
};
}and the invalidateModel() call results in marking of previous renderings of the page as stale. for example, the rendering of the page you can get to with the back button in the browser, which will have one more row than the current page in the browser.
my advice in general about attempting to do any component caching/sharing is that it is probably a good way to get burned if you're not careful. we do need a best-practices document on this, but i'm too busy working on the core right now to get that done.
anyway, the whole design of wicket is contrary to the idea of trying to share components to save memory. a page can re-render itself and that is about as much reuse as there is. the basic paradigm is to just contruct pages along with all those nested components wholesale. yes, this DOES cost something. but what it costs is a commodity item (memory and CPU) while what wicket saves (programming effort and time-to-market) is relatively precious. if you want to scale wicket, just keep things simple, robust, secure, flexible, etc... don't optimize prematurely... and buy more $300 emachines servers.
Jonathan Carlson wrote:
Thanks. I thought I had noticed the opposite behavior (new components being created for each hit) but that must be due to the way I was creating my components. I better look at the examples more closely.
If each page is cached in the session, how does it handle different browser windows using the same session and accessing the same page with different data? Sorry for my ignorance on this, but I guess I should understand this before I go any further. If it's in the docs and I just missed it feel free to direct me there.
- Jonathan
>>> [EMAIL PROTECTED] 2005-02-07 2:29:04 PM >>> i'm not sure what you mean by "service objects", but wicket doesn't generally provide for directly putting stuff in the session. it's not necessary because applications, pages and components are all first class objects that are part of the session. so generally, you don't touch the session. instead, you just create a field in your subclass in the usual OO fashion. make sense? this issue comes up a bunch, so i think i'll add a FAQ entry on this issue.
jon
Jonathan Carlson wrote:
> I am wondering what wicket might provide for caching service objects
> somewhere in session-scope or application-scope.
> > For example, I could just use the standard Servlet APIs for putting
> objects into the session, but I wanted to know if Wicket
> provided anything more convenient for stuff like that. Eventually, I
> will probably use PicoContainer for dependency injection, but my needs
> at the moment are pretty basic.
> > Thanks,
> > Jonathan
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
>
> www.katun.com <http://www.katun.com/>
> **********************************************************************
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click <http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click>
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
