Re: Chaining IComponentResolvers

[Juergen Donnerstag <ju...@gmail.com>]

You can: MarkupParser.appendMarkupFilter(final IMarkupFilter filter,
final Class beforeFilter)

Juergen


On 5/24/07, Al Maw <wi...@almaw.com> 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!
> >
>
>

Re: Chaining IComponentResolvers

[Eelco Hillenius <ee...@gmail.com>]

But the component resolver is too eager. Look at the failing unit test
for an example.

Eelco

On 6/2/07, Juergen Donnerstag <ju...@gmail.com> wrote:
> You can: MarkupParser.appendMarkupFilter(final IMarkupFilter filter,
> final Class beforeFilter)
>
> Juergen
>
>
> On 5/24/07, Al Maw <wi...@almaw.com> 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!
> > >
> >
> >
>