[
https://issues.apache.org/jira/browse/WICKET-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juergen Donnerstag resolved WICKET-590.
---------------------------------------
Resolution: Fixed
This problem is not related to IMarkupFilter but IComponentResolver. And what
you suggested is not necessary. Auto-added components do execute behaviors
added to ComponentTags.
> RelativePathPrefixHandler and WicketMessageTagHandler conflict
> --------------------------------------------------------------
>
> Key: WICKET-590
> URL: https://issues.apache.org/jira/browse/WICKET-590
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: trunk
> Reporter: Alastair Maw
> Fix For: 1.3.0-rc1
>
>
> We have a bit of an issue with IMarkupFilter implementations, in that you
> can't currently layer two different IComponentResolvers if they both want to
> alter the same thing.
> This is currently an issue for SimplePageTest for testRenderHomePage_7, which
> is why that's failing.
> Specifically, it goes:
> <input type="image"
> src="test.gif"
> wicket:message="attr-name:i18n-key">test 2</input>
> Correct behaviour here is:
> - Prepend the src attribute with "../" links to make it
> context-relative.
> - Add an attribute "attr-name" with the appropriate i18n message.
> MarkupParser adds WicketMessageTagHandler is before the
> RelativePathPrefixHandler, so currently that "wins" and resolves the
> component first. It doesn't get added as a RelativePathPrefixHandler auto-add
> component, so the behaviour to prefix URLs isn't added, so the src attribute
> remains "test.gif", not "../test.gif" and the test fails.
> We need to somehow support chaining these things together, but I'm not sure
> how - it's really not obvious.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
