When actually work with multiple pages (popups?) there's allways some more work needed to keep your windows synchronized. Personally, I try to avoid working with more than one window at the time, though sometimes a simple popup can be handy.

When you create a popup, there will be a new page instance created, so you can't use the instance variables of another one (at least not without hacking). Now, you've got two possibilities for synchronizing your windows:
1. Use the HttpSession. It's there. It's just hidden, so that people hopelfully will see this is the last resort we think it is.
2. (Preferably) Use detachable models with your components. That way, your data will allways be fresh automatically on each request, and you don't have to do much (if anything) to synchronize. One pittfall could be that your popup changes structural components like trees and lists. If that is the case, be sure that those components are invalidated (e.g. on a ListView call invalidateModel) so that it's subcomponents will be removed in order to have a clean render next view. There's a million ways to do this (e.g. using your models with an observer pattern), but a nice OO practice how to come up with the nicest.


Hope that helps,

Eelco


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

Reply via email to