On Wed, Nov 07, 2007 at 07:14:01PM +0100, Korbinian Bachl wrote:
> > Given these subtle problems with this approach, I admit I'm warming to
> > the multiple extend/child idea.
>
> im oposite - if i have X extends in a page, whose extend should be
> preferred (e.g: manipulating the head or a part outside of itself) ?
Perhaps I don't understand your argument, but it sounds like you're
interpreting this as some sort of multiple inheritance thing. I like to
look at it this way:
- a Wicket page is a Java class and some markup.
- there are three ways a page can acquire its markup
- it can have its own
- it can inherit it from a base class
- it can *mostly* inherit it from a base class, but inject some
additional markup into the parent markup at a place specified by
the parent markup
All the current proposal does is allow the parent markup to advertise
multiple places where children can inject their markup. Yes, there are
difficulties with this. Child pages have to be careful about component
ID collisions, the framework has to sort out multiple header
contributions from children and grandchildren, etc., but these problems
are present in the current single extend/child approach. I can't see any
additional ambiguities introduced by allowing additional markup
injection sites.
> my override of onBeforeRender is secure from your point and IMHO more
> easy...
I suggest it's not so easy for average Java developers starting out with
Wicket. In my experience, many Java developers are unaware of the "don't
call non-private, non-final methods from constructors" rule. Further,
once you've been bitten by that problem, it's not clear that using
onBeforeRender is the answer. And once you've figured *that* out, it's
not clear that you have to protect against multiple invocations.
jk
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
