In this discussion Peter mentioned Hibernate as an example framework. Hibernate /does not/ compare to Wicket. Hibernate is a utility framework in that you normally don't have to extend anything from the Hibernate packages in order to be able to use it. I have yet to meet anyone who implemented his own Session, Query or Criteria object. __________________________ I didn`t mention Hibernate. I mentioned the Collection Framework/Spring and the new concurrency Framework. And for all these frameworks I have created different implementations countless times (especially the Collection framework). But I understand the arguments about not making it an interface and I strongly agree with making methods final if they are not meant to be subclasses. To come back the the reason I asked why: I haven`t been able (so far) the let Spring generate proxies with security and transactions and that was the reason I brought this question up in the firstplace. If this could be fixed in some way, I would be a very happy man. It will save me a lot of time and the application will have a cleaner and better to understand structure -> all creating of objects in Spring. What I want: With my current Spring configuration, Spring checks if a new bean (could be a page) has any annotations, and if it does, it tries to create a proxy which delegates all calls to true implementation but enhances some with extra functionality. Like transactions, security etc. With my objects it is no problem (I have an interface with annotations and an implementation.. although I only use an interface (most time) just for the sake of proxying.
And lets agree that we disagree. Personally I don`t think the interface vs class discussion(s) are very interesting. I have given arguments countless times and I guess you do to. We both are not going to change so there is no point discussing it any further.. Wicket is a component framework which thrives on extensions. Everything on a web page and the web page itself in Wicket is a component. In order to work with those components, Wicket needs more information and needs correct meaning in the right places. *A LOT* of thought has gone into providing extension points through inheritence. Wicket is meant to be extended by creating your own components. Depending on your needs, you can extend at any level in the hierarchy, but the Wicket core is always certain that the components behave in the intended manner. > In a public framework it is always beneficial to provide interfaces > for users to extend, even if you have abstract convenience classes to > speed development. No, Wicket isn't about convenience classes to speed development. Wicket /is/ the component *hierarchy*. > Having interfaces have never "broken" a framework that I'm aware of. But they have stooped development of that framework. An interface is cast into concrete. Once you have it, you can't change it. Period. > What, exactly is the harm in having an IPage interface in the > framework? If users don't implement the contract of the Page with > the framework, it isn't going to work. Interfaces don't give a contract for behaviour. Our components are well behaved within the context of Wicket. This behaviour is what makes Wicket tick. It is what brings you the richness of our components. Implementing some public interface doesn't give you the intended behaviour. You'd still have to extend WebPage in order to behave within the context of Wicket. How do you envision having an IPage interface help our users? What kind of new implementation would you provide that will work seemlessly with Wicket without having the internal knowledge of how pages should react? The only thing I can see now that would actually be a new implementation of the Page concept is WapPage. But the WAP protocol utilizes a rather different request cycle, as far as I know, and /really/ has a different component hierarchy. So mixing WapPage and WebPage will not be a good thing. Perhaps when Wicket has reached 2.0 or so when we understand where Wicket has brought us, we will utilize interfaces to the fullest, but until then, we need the flexibility to be able to implement new features into our framework. Currently it is not clear what the interface should look like and I don't see this clarifying itself in the foreseeable future. Martijn Vince Marco wrote: > I've got to go with Peter on this one. In a public framework it is > always beneficial to provide interfaces for users to extend, even if > you have abstract convenience classes to speed development. > > While I agree with Jonathan that larger interfaces are problematic > and restrictive, that's not the only criterion for good interface > design. You also need to balance that with the number of interfaces > presented to the developer. It seems to me that a Page is a visible > construct of the browser and HTTP request-response cycle that > developers are familiar with. I wouldn't underestimate the value of > a Page interface for users, especially since one of the main classes > you are asking them to subclass is a WebPage. I see value in an > IPage interface, perhaps comprised of a number of sub-interfaces. > > And sure users could extract their own interfaces, but I thought that > Wicket by being a web framework, was in the business of doing things > like that for users. > > What, exactly is the harm in having an IPage interface in the > framework? If users don't implement the contract of the Page with > the framework, it isn't going to work. If they do, then Wicket will > suit their custom needs. It doesn't mean the WebPage class is going > away. Having interfaces have never "broken" a framework that I'm > aware of. Changing interfaces can determine incompatibilities > between versions. > > My 2 cents. > > Vince > > > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > <http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click> > _______________________________________________ > Wicket-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-user > <https://lists.sourceforge.net/lists/listinfo/wicket-user> > ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click <http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click> _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user <https://lists.sourceforge.net/lists/listinfo/wicket-user>
<<winmail.dat>>
