On Saturday 20 May 2006 19:25, Johan Compagner wrote: > 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 ");
Ok, cool. That will do for now... > 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. ...and we step up the collaboration when you go towards 2.0 and we have some more serious experience. > 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? As I said, we have a pretty good idea that we would need to clear the cache on bundle loading activity. Just that we don't do that at the moment (the message was also directed towards people who are interested and want to try it out, letting them know what is missing in our part...) So no worries from Wicket team needed ;o) > 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. 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? > > 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) 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? Thanks a lot for the information so far... I hope to turn this into a killer demonstration of what you can do, when combining a real dynamic runtime platform with a sweet, xml-free, object-oriented, no non-sense web application framework, made by people who obviously think more than "the others"... Cheers Niclas P.S. Is there any link on the "History of Wicket"??? ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
