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
