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
