On 19/12/13 18:45, Martin Grigorov wrote: > So far no one needed to add custom MarkupElements and that's why it is not > very easy. > You can fork Wicket and create a branch where you can make modifications to > make it easier and > later we can review the needed changes and probably apply them back in > Wicket.
Hi Martin, I've found a way to achieve the goal of immutable markup. It's basically what we were talking about with a subclass of ComponentTag and RawMarkup. And I've found a better way to hook into wicket to generate this Markup by adding a MarkupFilter to the MarkupParser. This has the advantage of not even needing to subclass Markup as I can replace MarkupElements in MarkupFilter#postProcess. There's also huge benefits in the wicket-el code... Removing the need for quite a bit of complex code to manage situations where an EL component has associated markup that contains expressions that belong to one of it's child components. The only change needed to wicket to achieve this is removing the 'final' modifier from the RawMarkup class. I haven't been able to fully test it yet as I'm having trouble getting wicket-core to compile in eclipse. But it's very clear that the approach will work. So what it is the best way to go about requesting a change to wicket-core? I'm happy to fork and create a pull request etc but it seems overkill for removing a single word from one class. Should I create a JIRA ticket perhaps? I imagine I'll need to maintain the current implementation for a while as if the request change to RawMarkup is accepted it will take some time for it to appear in a release version. Any idea how long that would take? --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
