Hmmm... A "version" is probably a key word here, that I don't fully
understand.
The real question is; Does ALL page creation happen through the
IPageFactory.newPage() methods? I suspect not, since everything is required
to be Serializable, which means that deserialization is another way the page
can be created. And if so, what is the "user result" if the deserialization
fails?
Also, the deserialization would require to load the classes that makes up that
serialization stream, unless it is a MarshalledObject which keeps the
codebases for each classloader involved in the serialization. Any pointer to
the answer of these thoughts?
I also guess that the developer can keep the page around indefinately, just by
adding/removing content on the same page. Is that correct?
First the pagefactory is only used by wicket to create bookmarkable pages.
After that it is the developers choice what to do. Of course he can use it also but i guess
99% of the devs do just: new UserPage(user);
second a page records changes to itself through its version manager.
This works just as the Undo Support of Swing. So it has a list of Change objects and in that change object
the previous value is kept. (like a previous panel that was replaced) and when we encounter a request to
a previous value we say to that change undo yourself. Then that change will get its value and set that value back
where it was. Then the page is again in the previous state, because all changes are rollbacked.
About serialization: Are you using OSGI on top of the web app (so inside the webapp)
or do you run the server itself in OSGI?
Because if you do the first then you have a big problem. Serialization will work. But deserialization will not work.
Because you introduce classloaders inside the webapp. This is fine as long as those classloaders don't supply
classes that makes objects that are stored in the session. Because how can the servlet container then find those classes?
As far as i know there is no solution for that except having full control over the servlet container itself..
> As i said before you can do as much as you like alter the structure of the
> page as you like (replacing panels and so on)
> that is no problem. Just know that if you want backbutton support you must
> also let the page version itself when it is changed
> (this is done by default)
Cool. We have the notification mechanism for that thought out, just need to
make it work, and some examples.
So, that includes removing components outside the request cycles? Thread-safe?
First if all it is not thread save by default. Second the version manager will not work correctly.
But the latter is something you want to by pass anyway. So if you change pages do turn off
the version managment for those changes and sync the page around its session object.
(that is pretty much what we do also when accessing the page)
So then it should be thread safe.
johan
