Sorry for the cross post, but I wanted to reply on the original message, but think that we can better go on with this discussion on the Wicket list. Answers below.
On 9/22/06, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > > > Btw, is Wicket 2.0 still scheduled for native OSGi support in some form > > > similar to what Pax Wicket offer?? > > > > The problem is that I'm merely a lurker here, in case anything Wicket > > specific comes up etc. I wish I had more time to look at what Pax > > Wicket does in detail, but so far I haven't found any. And that's the > > same for the other Wicket committers. > > The primary 'interesting' bit is that instead of programming the Wicket > components, Pax Wicket programmer establishes a "Model" of how the Wicket > components are to be assembled, and making it easy to modify that model in > runtime. > > > However, we would greatly appreciate any help when it comes to > > supporting OSGi in the best way we can. Are there any specific things > > you are thinking about at this moment? Any pointers to areas than can > > be improved? And how does the constructor change affect Pax Wicket? > > I am not sure. If we stick with Pax Wicket as it is, I don't think it changes > anything significant to do add() or constructor injection. It happens in the > same sequence for us anyway. > > What I was perhaps hoping for was a 'strategy' of how higher level dynamicity > can be achieved in Wicket thru usage of OSGi. Pax Wicket is probably not the > best way, just 'one way' possible using the Wicket 1.1/1.2 features > unmodified. > > What Pax Wicket support today is that the client application can be broken up > pieces and those parts are replaced on the fly without restarting the entire > application. It is also easy to separate the business logic from the view, > and hence get a better architecture in general. > The main missing part is that if Wicket is upgraded, e.g. from 1.2.1 to 1.2.2 > the Pax Wicket Service bundle will be reloaded and ALL client bundles will be > stopped, reloaded and restarted isnce they all reference wicket classes > directly. > We have been sketching opn elaborate schemes on how to support upgrades of the > Wicket classes without reload of the client bundles, but that quickly becomes > a large unwieldly mess of Bridge pattern and slow routings. > > The obvious OSGi-centric choice would be a Wicket that has full separation of > API from implementation, so that the implementation can be reloaded, but not > the API, without reloading the client bundles. However, then the general > approach would go from; > > Button b = new Button( parent, id, label ); > > to > > ButtonFactory factory = ... // get hold of it > IButton b = factory.create( p, id, label ); > > which probably has little support in the general Wicket community, unless > there is both... > > public class Button implements IButton > > And that the interface classes are placed in one bundle and the implementation > classes in another. > > Finally, getting the factory in normal Wicket would probably then be with > Spring, and the OSGi community would do it with Service lookup. > > Introduction of interfaces would mean a lot in OSGi terms, but I understand > that it could be felt unnecessary in Wicket community at large. > Yeah, I don't see such a factory pattern happen very fast with Wicket. It's kind of the one thing we're doing different from other frameworks, and for a good reason we think. The factory wouldn't need to be part of Wicket, as that's something you (or some 3rd party lib) could easily provide yourself. We're not that against backing our widgets with interfaces though, provided we found some meaningful ones. And here is where the main problem lies: how can we extract interfaces that truly reflect what components are, what their behavior is etc, in such a way that we have the guarantees we need. Take for instance that constructor change; there is no way we can force passing in a parent with an interface. Or force that IComponentInstantiationListeners are called for each component. Or... well, lots of other guarantees we need to make the framework work well. So, replacing Component with IComponent is just not something we believe in. That said, what we could look for is to find interfaces that would describe functionality in a specific context. For instance, IFormComponent, IForm, and maybe even IComponent, but a limited version that would be suitable for the purposes of using component factories like you described, but wouldn't replace the abstract Component class. I definitively would want to end up with horrible interfaces like some of our competing frameworks employ (sorry if that sounds cocky) but now that Wicket matures and the API get more and more stable, I would feel more confident about thinking about some proper interfaces where that would make sense. > > We could open up a discussion either here or - probably better - on > > the wicket-develop list to discuss this. > > You have so much traffic there :o) Hard to keep up, even though I try to look > out for topics that interests me. > > > As a side note, we're nearing 2/3rd of Wicket In Action, and in the > > last part, which will be written over the next three months, we're > > still considering writing something about Wicket and OSGi. In that > > respect, I would be very interested to learn about how people use OSGi > > and web applications together. What are the pro's and con's, and in > > what kind of scenarios did you use it? > > Not sure that it has been used that much in professional deployments yet. > ScanCoin is however one deployment inside cash handling machines (ATMs and > such), where the UI components are loaded and discovered via UI provider > bundles. > For instance; Each hardware component provides its own troubleshooting panel, > which gets added onto an AjaxTabbedPanel. In machines where the hardware is > not installed, the bundle that handles the hardware is not loaded and no > panel in the UI. > Due to the flexible Pax Wicket model, this is very easy to express, as one > can 'wire' the Pax Wicket "Content" to "ContentContainers" in runtime and > don't need to know where it is going to reside in the larger > picture. "Content" is essentially a model of a Wicket component, and > the "Content" will be asked to assemble the Wicket component in the hierarchy > it sits at request time. > > Cheers > Niclas > > _______________________________________________ > general mailing list > general@lists.ops4j.org > http://lists.ops4j.org/mailman/listinfo/general > Anyone else want to chip in? Eelco ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
