I ran into the issue described in this topic: http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-td11277169i20.html
Basically wicket started to override the markup IDs with auto-generated stuff, and I needed to reclaim the ownership of those IDs. So, as I wait for a solution/patch from the wicket dev team, I was trying to figure out a workaround that allows me to adapt my application without the need of do lots of setMarkupId() calls or to redefine the whole component hierarchy changing the default value of setOutputMarkupId() to true. Then I digged into the code, looking for a place to change the markup Id overriding policy itself. In general when I do that stuff I expect not to change the jar itself, but to identify the piece that I want to change and build my own extension/implementation of it without touching the code base. To my dissapointment, I've found that the whole rendering policy is inside the very Cojmponent class, so if I want to change it, I need to redefine the whole component hierarchy. This made me remember... struts. What do you guys think of the idea of having this kind of responsibilities delegated in separated pieces that we can inject and change? Say, Component should rely on a "Renderer", or "RenderedPolicy" interface, and the package should provide a default implementation of the interface that one could override through some little programming on the WebApplication extension you made for the app. -- View this message in context: http://www.nabble.com/Start-delegating-stuff-out-of-Component--tp15884385p15884385.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
