Explain the internal working of Wicket's markup inheritance resolution?

When a Page or Panel subclass extends a parent that defines wicket:child, Wicket has to merge two separate HTML files into a single logical markup structure before it can render anything, and it does that merge once, at markup-loading time, rather than on every request.

Wicket loads the subclass's own HTML, and if it finds a wicket:extend block, walks up the Java class hierarchy to load the superclass's markup too, splicing the subclass's content into wherever the superclass declared wicket:child. This walk continues recursively if the superclass itself extends yet another markup-inheriting class, so a three- or four-level inheritance chain resolves correctly without any special-casing beyond repeating the same splice operation at each level.

Because this merged markup structure is cached after being resolved once, the recursive walk-and-splice cost is paid only the first time a given page class's markup is needed, not on every single request — a request that reuses an already-resolved class just renders against the cached merged structure directly.