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
