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
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
