I'm already salivating, thinking of all the possibilities... My life will be complete once 3.0 comes out! :-)
On Sat, 2006-09-23 at 11:37 -0700, Eelco Hillenius wrote: > Niclas, as you can see, we would be open for it, but not too soon. I > opened up an RFE here > http://sourceforge.net/tracker/index.php?func=detail&aid=1564174&group_id=119783&atid=684978 > > We currently have no idea when Wicket 3.0 will be worked on. Wicket > 2.0 is still in alpha, though that'll change shortly, but it'll take a > while before we are ready to start on 3.0. At least half a year I > would say. Anyway, by the time we get there, this will be one of the > major efforts for that release (together with a drastic refactoring of > our markup handling I think). > > Eelco > > > On 9/23/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > i agree, this wont be a quick and easy change. i dont think because wicket > > 3.0 is based on interfaces, shall we decide to do that, the book will be > > useless. all the concepts are the same - and thats what the book is there to > > teach mostly. > > > > besides, we wont be starting on 3.0 for a pretty long time. > > > > -Igor > > > > > > > > On 9/23/06, Juergen Donnerstag < [EMAIL PROTECTED]> wrote: > > > Because it'll take several iterations to find the right interfaces I > > > suggest to make the changes in 3.0 > > > > > > Juergen > > > > > > On 9/23/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > If we plan on getting more interfaces in, it has to be done very soon, > > > > or it'll be for 3.0. Unless we want Wicket In Action to be completely > > > > useless :) > > > > > > > > Eelco > > > > > > > > > > > > On 9/22/06, Igor Vaynberg <[EMAIL PROTECTED] > wrote: > > > > > re interfaces, > > > > > > > > > > you know me, ive always wanted wicket to be based on interfaces, but > > good > > > > > arguments have always been made against them - but only if you think > > about > > > > > interfaces in a traditional way and that is as integration points > > between > > > > > two entities - the service provider and the service consumer. the > > > > > traditional point of view is that interfaces should be well defined > > from the > > > > > beginning and should not change. > > > > > > > > > > but then how can any system that defines interfaces evolve? i dont > > think > > > > > this is a good argument, api breaks are api breaks whether they happen > > in > > > > > interfaces or in some classes that are not backed by interfaces. > > > > > > > > > > another argument against interfaces is that no one ever will provide > > their > > > > > own implementation of IComponent because there would be no point, so > > why > > > > > have an interface?. i agree with this. in this sense the interfaces > > are > > > > > useless in wicket - Component has too much functionality that people > > would > > > > > have to replicate, its not worth the effort. > > > > > > > > > > but consider what interfaces get us that concrete classes dont outside > > these > > > > > arguments. > > > > > > > > > > 1) we get an easy way to proxy things > > > > > 2) makes aop easier - connected to (1) > > > > > 3) it obviously has a lot of advantages for osgi - at least for wicket > > > > > releases that maintain binary compatibility in the interfaces. > > > > > 4) whatever i missed in 1-3 > > > > > > > > > > yes there will be a lot of single interface - single implementation, > > which > > > > > some people might think of as an anti-pattern. > > > > > > > > > > but look at what we have now - we have a lot of interfaces that really > > > > > should extend IComponent but they dont and thus add a lot of weirdness > > > > > because they lack scope. take a look at IPageable - yes it is nice and > > > > > simple - defines anything that can be paged. but in all the cases you > > are > > > > > using it you really wish you can just cast that bad boy to Component > > instead > > > > > of having to pass in the same object twice - once as component and > > once is > > > > > IPageable. NASTY. > > > > > > > > > > another great argument is that IComponent would be a BFI. yes it will, > > but > > > > > maybe what we can do is break it into a lot of small interfaces and > > have > > > > > IComponent aggregate these. > > > > > > > > > > for example > > > > > > > > > > IFeedbackAware { error(String); info(String); FeedbackMessages > > > > > getFeedbackMessages(); } > > > > > > > > > > IRequestCycleAware { getRequestCycle(); setResponsePage(Page); > > urlFor(*); } > > > > > > > > > > IRenderable { render(MarkupStream); } // we already have this for > > light > > > > > weight components in the tree > > > > > > > > > > IComponent extends IFeedbackAware, IRequestCycleAware, IRenderable, > > etc... { > > > > > isVisible(); setVisible(); etc > > > > > } > > > > > > > > > > so in this way IComponent doesnt have to be huge. dont know if this > > really > > > > > helps or not. > > > > > > > > > > im still on the fence - but i can see the appeal of having them in > > wicket. > > > > > > > > > > -Igor > > > > > > > > > > > > > > > > > > > > On 9/22/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------- > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------- > > > > 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 > > > > > > > > > > > > ------------------------------------------------------------------------- > > > 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 > > > > > > > > > ------------------------------------------------------------------------- > > 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 > > > > > > > > ------------------------------------------------------------------------- > 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 ------------------------------------------------------------------------- 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
