But the component resolver is too eager. Look at the failing unit test for an example.
Eelco On 6/2/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
You can: MarkupParser.appendMarkupFilter(final IMarkupFilter filter, final Class beforeFilter) Juergen On 5/24/07, Al Maw <[EMAIL PROTECTED]> wrote: > Hi, > > I've created a bug for this. > https://issues.apache.org/jira/browse/WICKET-590 > > It's currently causing the build to fail - we really should fix this one > way or another. > > Al > > > Al Maw wrote: > > Hi folks, > > > > 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. > > > > I wondered if anyone out there might have any bright ideas how best to > > fix this. > > > > Al > > > > !DSPAM:465435e2192032419821387! > > > >
