Nbr 1 reason currently: because no-one yet came with a convincing case
of why we would need it. All developers are against it (haven't heard
from Chris and Juergen, but my guess is we're on the same line here),
and we want to end this discussion now. Btw, a remark that Johan made
offline: it would be kind of the same discussion as why Swing's Window
or SWT's Shell is not backed by interfaces. It's a design decision that
was made with what we think are good reasons.
If people really think it is important for them, they can add an RFE for
1.2 or up. That RFE should include at least one really convincing use
case of why the current set up would be limiting for them, and why they
couldn't achieve the same goals by simply subclassing (and maybe attach
their own interfaces).
Eelco
Gili wrote:
Hmm, maybe this isn't an all or nothing case. Why can't a Page
consist of many smaller interfaces that it implements?
Gili
Eelco Hillenius wrote:
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.
I would agree with often, not with allways. I think in Wicket's case,
there is too much behaviour to create a good interface from. Again my
question: what would that interface look like? If I look at the page
interface of one of the frameworks we are competing with, I see a lot
of methods of which I think do not belong in a clean interface
(getThis, getThat); stuff that doesn't point to a clear type, nor to
a very specific type's behaviour.
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.
I would like to turn this discussion around. I would like to know
/why/. For what exact reasons - except for stylistic reasons - does
it add value for you that Wicket pages are backed by interfaces? What
would you do that you couldn't do with subclassing?
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.
In being a framework, Wicket tries to provide a lot of flexibility in
some areas, while limiting it on purpose (for reasons of
evolvability, and having a tigh API with shallow conceptual serface)
in other areas. Jonathan made a design decision not to use
interfaces, and if I had to choose now, I'd choose the same.
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.
Changing interfaces in a business system with just a few clients is
not such a big deal. However, we strife to be a framework that is
used by a lot of users, so we want to be very considerate before we
break a lot of stuff for users all the time.
But... as long as people inherit from (Web)Page, there wouldn't still
be a lot of problems, as WebPage would evolve with the interface.
However, the big problems start when we provide an interface and
people actually begin to depend on that interface directly. My
problems with that are:
- We hide a lot of behaviour in pages and components. If we would
have to extract that behaviour to be reflected in the interface, that
would be a hard job, and it would seriously limit our options of
refactoring the internals. And we would /need/ to extract the
behaviour to the interfaces, because otherwise our interfaces would
be meaningless.
- Every interface change would break all clients that depend on the
interface immediately. Not so much the case with abstract classes, as
we have much more options of keeping things internal.
So, as I think this is really important, let me put this another way:
having interfaces for pages and components is not a good idea because
to get interfaces that are actually meaningful, and that reflect the
behaviour of what they abstract, we would have to pull a lot of our
current internal behaviour (usually our final methods) to the public
interfaces where they are not final, allways public, and part of the
complete contract that implementors have to obey.
My 2 cents.
Vince
My 2 cents too, though my opinion is very strong on this.
That doesn't mean there is no discussion possible about this, but I'd
really like to see some convincing use cases why people would want to
have such interfaces, as it would be a very big deal to the current
developers (who I think all agree on /not/ having interfaces) to
change this.
Regards,
Eelco
-------------------------------------------------------
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
-------------------------------------------------------
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
