Hi Vahid,
This feature has been requested multiple times in the Wicket's long history.
There have even been times where implementations of this feature have
been developed but unfortunately not added to the Wicket code base,
apparently due to backwards compatibility issues but I believe there are
trivial ways to make the current "single overridable component"
limitation supported in a backwards compatible way.
Sometimes this feature request was incorrectly compared to "multiple
inheritance" (which most OOers agree is evil) but this feature is
clearly not a case of multiple inheritance as this feature does not
require one "derived/extended" markup file to ever "derive/extend" from
more than one "super/base" markup file - which is the definition of
multiple inheritance.
Rather, it proposes that multiple components within a single markup file
can be overridden (even optionally!) in an extending markup file.
An analogy is in Java where, with no support for multiple inheritance,
one can override more than one method of a super class in an extended
class and yet still be constrained to extending only a single super class.
If you want to track back over the history of this feature here are some
links to previous "impassioned" discussions:
https://lists.apache.org/thread/sc0ly7h2ft9h8rvqqvf3rv8ydnvp2xnz
https://lists.apache.org/thread/td25to87wp46db2j3wkm26nrs635lwcv
https://lists.apache.org/thread/gh8q2p4l3bq64qcy3fpxhon6z28kh4dy
This one was an attempt to summarize long discussions on the topic:
https://lists.apache.org/thread/k83ozgol45on6cnydgmphj9q0cvo9ppo
These days we exclusively use Wicket for all web apps we develop. 12
years ago we knew that the cleanliness of design and markup that we
could achieve with the ability to (optionally) override more than one
component within a given markup file was overwhelming attractive to us.
However, the inability of Wicket to support that feature lead us to
develop our own "wicket markup pre-parser" which takes markup with
enhanced, extra tags that support the optional overriding of multiple
components within a Wicket page (i.e. non Wicket compatible) and then,
from these, regenerates multiple "flattened" markup files that are
Wicket compatible markup files.
It means we need to regenerate using our pre-parser whenever we change
one of these "custom" Wicket markup files (not very frequent) but the
end result is a much cleaner design with an easy to maintain set of
markup files.
I mention "optional" component overriding a few times because I believe
that is a very useful part of standard inheritance in OO languages like
Java - a derived class is not "forced" to override all overridable
methods in a base class - that would be most burdensome and frustrating.
Rather, if the behavior of a method in a base class is useful in
multiple subclasses then it can be used as a "default" by simply not
overriding it.
I always thought that would be useful in Wicket's markup inheritance as
well but unfortunately the current implementation in Wicket mandates
that a <wicket:child> "component" be overridden - which is,
conceptually, is not such a problem when you are constrained to a single
overridable component (given that you would only be overriding a markup
file for the purpose of overriding that single component) - however when
you support multiple overridable components, as our pre-parser does, it
becomes extremely useful to support optional overridability rather than
mandatory overridability.
Regards,
Chris
On 9/01/2022 11:55 pm, vahid ghasemi wrote:
Hello,
How can I use 2 wicket:child for 1 inherited class?
Like this:
<h1>Hello</h1>
<wicket:child child-id ="first">
<h2>Hello</h2>
<wicket:child child-id ="second">
<wicket:extend id="first">
<h1>Hello again</h1>
<wicket:extend id="second">
<h2>Hello again</h2>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
