On 9/23/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
So I suspectde... ;o)
Correct.
Well, any method that is considered part of the official API would need to be exposed via an interface, since casting down to the implementation would not be possible in the OSGi scenario, as the 'client code' would not be able to reference such type.
Well, the factories would be responsible to enforce the constructor requirements, which very well can be 'official SPI specification'.
As I see it (and I don't feel like an expert in the area), Component fulfills two purposes in the same class.
1. API - methods that are common for usage from cilent code.
2. SPI - methods/functionality available to Component subclasses.
IMHO, it should be too hard to figure out what is what in this particular case, and then extract the API into one or more interfaces.
The "inheritence" vs "delegation" and "abstract classes" vs "interfaces" wars always brings bitter feuds among sensible people. I don't want to start such here, so I think before discussing details, a policy or ambition statement must be made in Wicket community of the direction to take and then stick to that.
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.
So I suspectde... ;o)
The factory wouldn't need
to be part of Wicket, as that's something you (or some 3rd party lib)
could easily provide yourself.
Correct.
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.
Well, any method that is considered part of the official API would need to be exposed via an interface, since casting down to the implementation would not be possible in the OSGi scenario, as the 'client code' would not be able to reference such type.
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.
Well, the factories would be responsible to enforce the constructor requirements, which very well can be 'official SPI specification'.
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.
As I see it (and I don't feel like an expert in the area), Component fulfills two purposes in the same class.
1. API - methods that are common for usage from cilent code.
2. SPI - methods/functionality available to Component subclasses.
IMHO, it should be too hard to figure out what is what in this particular case, and then extract the API into one or more interfaces.
Cheers
Niclas
------------------------------------------------------------------------- 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
