Would be page interface enough? I mean, the only current usecase that
were here presented is AOP, which IMHO would be nice to have but I'm
afraid it's not worth the complication it would introduce.
In my application, most of the actions belong to components. Forms,
Links, even more complicated one like MailEditor, etc. In my
application, the components do actions without actual knowing to which
page they belong. So I think having interfaces for pages would also need
having interfaces for components. Otherwise it would be only half-baked
solution. Now considering wicket request cycle management and the actual
quite complication behavior of components, I can hardly imagine anyone
developing his own components/pages from scratch.
-Matej
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
