Hi Bas- I would love to chat more with you and Jonathan on this!
I sent over an invite to the #wicket Slack channel to you, let us know if you are up for digging into this together. Thanks! Matt Pavlovich > On Nov 13, 2025, at 1:03 AM, Bas Gooren <[email protected]> wrote: > > Hi Jon, > > Thanks for creating Wicket :-) > > The first part of your message implies to me that you want to merge the > markup of MyComponentDecorated.html and MyComponent.html - is that correct? > Because I don’t read that in this sentence ("To restate the problem, what I > want to do is have MyComponent load either MyComponent.html or > MyComponentDecorated.html depending on the state of some variables > associated with MyComponent.”). > > The simplest way to do this is with a variation, I think. Perhaps there are > better ways, but it worked well for me so far. > Basically - switch between variations by overriding > “Component#getVariation()” for a particular component and then wicket > automatically tries to load that variation of markup. > > Based on your state you can return null or “decorated” from getVariation() > and thus use MyComponent.html or MyComponent_decorated.html; > That does mean that you need to repeat the html in MyComponent.html in > MyComponent_decorated.html and add any extra html there. So no automatic > merging and some duplication of the “base” html. > > Now having said the above, and having hacked quite some of the wicket > internals: markup merging happens at load time. > So If you really wanted to do this, I think you’ll need to manage it > yourself. But since you are dealing with a single MyComponent which has two > different markup variations, the default classes will not work > (InheritedMarkupMarkupLoader expects a wicket:extends tag to reference a > parent component for the “parent” markup). > Should not be that difficult to make this work, but will involve a custom > markup loader and some custom logic for getMarkupResourceStream(), as you > were already working on. > > Usually when I consider going down a rabbit hole like that, I first ask > myself: is that really worth the effort and maintenance burden? 🙂 > I guess it depends based on how many components like this you have and/or > if you are getting the html from an external system (and thus need to work > with that). > > Another strategy I would consider here is putting the “decorated” > components inside a fragment, co-located inside MyComponent.html. > Then you can either dynamically show/hide or swap the decorated fragment > with an EmptyPanel based on your internal state. > > Met vriendelijke groet, > Kind regards, > > Bas Gooren > > > Op 13 nov 2025, 00:36:39 schreef Jonathan Locke <[email protected]>: > >> Hello All! >> >> I seem to have discovered after quite a lot of effort that it's not >> possible to dynamically swap the markup of a base component from which >> children inherit markup with <wicket:child/> and <wicket:extend/>. I think >> this makes sense because of how wicket merging and caching work (or at >> least used to work), but I just wanted to make sure that this is the case >> because it's been a long time since I worked on Wicket internals. To >> restate the problem, what I want to do is have MyComponent load either >> MyComponent.html or MyComponentDecorated.html depending on the state of >> some variables associated with MyComponent. In the case where the component >> is decorated, some components might be added and those components would be >> referenced in MyComponentDecorated.html. In the case where there are no >> decorations applied to the component, then no decorative components would >> be added and MyComponent.html would not provide references to decorations. >> I've tried a variety of ways of doing this, but it does not seem to be >> possible. I thought I had it for a moment by overriding both >> getMarkupResourceStream and getCacheKey, but that effort failed as well. >> >> Thoughts? Ideas? Thanks! >> >> Best, >> >> Jon >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
