Hi Chris,
i rewinded some part of your idea and the thread and now see bit clearer
what you want - perhaps you shouldnt call i multiple extend/child but
more precisely "inheritance with multiple areas" as you go:
html-basepage:
...
<extend id="foo" />
....
<extend id="faa" />
....
<wicket:child/>
....
while each those areas are then subsidarily taken over by 1 single
extended specialised class - so you somehow do nearly the same what I
did but put the abstract part into the HTML part... is this right?
If im right with this then its IMHO a bit shorter as my way, but on the
tradeoff that you may get bitten by an HTML-java binding error at
runtime as well as I still dont know how you want to solve the trouble
with the name-space (the thing Igor mentioned)
However, i know how hard the first steps in these directions are as i
went through them by my own... now, after im not more so focused on a
traditional way of doing webapps i often see things a different way -
e.g.: I even like Model's now, which also caused me much headache at the
first time
Best,
Korbinian
Chris Colman schrieb:
Chris Colman schrieb:
The beauty of the multiple extend/child idea is that it's not a
completely new concept we're talking about here - it's merely an
issue
of supporting n>1 instead of arbitrarily fixing n=1 like it is now.
1 Question: Who dominates Who and Why?
If you extend 1 class by class you create specialisations that
dominate
each other, but here you just mess together some classes - so why
should
which class dominate? If we manipulate a headertag? If we have same
namespace? If we have different securitylevels? Wich class is
responsible for all this? Why?
Dunno what you mean by "dominate" or "mess together some classes". No
one is talking about mess - the whole point of this feature is avoidance
of mess - in the same way OO brings about reduced complexity in code the
same thing can happen with markup.
We're not proposing multiple inheritance - which indeed causes mess.
We're talking single inheritance which means single lineage. Each page
only has a single base page. It's easy for Wicket to perform the
resolutions and merge markup from base and derived pages.
I know this because it already does it and it works fine. We're just
proposing to remove the restriction that it can only do it for just one
section of your base page - that's all, nothing revolutionary - just
evolutionary.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]