Ok, so there are still some outstanding issues;
1. Wicket-extensions is using a scanning of Jars/Zips approach to locate the
_javascript_ for the UploadProgressBar, which fails due to the OSGi frameworks
are not using standard URLs (zip/jar or file) for the resources, and hence
not scannable. I have suggested to Wicket that the location of the JS in
question is done with a direct reference, instead of the regexp. That should
work, but I am not sure if there are some additional thoughts why the regexp
has been chosen. We have had to disable the UploadProgressBar, as we use the
wicket-extensions in our sample.
We tried this regexp because then you can register complete dirs at once. Including
js, css and images.
So that you don't have to do it one at a time.
But for the upload bar we only find one so i guess we can do:
PackageResource.bind(application, ComponentInitializer.class,"progressbar.js");
in 2.0 we hope to get rid of the pre register of things. And then we also need to
work together how to do it then in OSGI. Because we need to have all youre classloaders then somehow.
2. Wicket has a MarkupCache which will hold on to various resources. If it
can't find it, it will store that information into the cache as well, so even
if the resource becomes available, it will not be served in a later request.
This can probably be solved simply by clearing the cache on each change of
the OSGi service registrations, and doesn't require any changes to Wicket.
yeah that NO_MARKUP target (or something like that) is just for performance so that we don't
test for the same thing over and over again. We could make this a setting?
3. We have not been able to fully understand the life cycle of a Page
instance in Wicket, and hope for some expert advice on the matter. Dynamic
changes to the component hierarchy will only occur when the page is created,
hence the need to understand this in detail.
A page is created by a bookmarkable request or by yourself (when doing new XxxPage())
then it is stored in the pagemap until it falls out of it in 1.2 this is by default 7 pages or version of pages.
If you hit it again through a form submit or link click. Then you hit that instance that is kept in the session
Then you can alter the structure and this is getting recorded as a version of the page.
This can happen over and over again. Until the page last used version is also least recent used and it is discarded completely from memory.
5. Wicket supports the removal of components from containers, but we have no
experience in what one is allowed and not allowed to do and "when" such can
be done. As for now, we don't try to modify a created page in Wicket, but
asking for any advice in the matter from experienced Wicket developers.
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)
johan
