You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Al Maw <wi...@almaw.com> on 2007/05/23 14:38:31 UTC
Chaining IComponentResolvers
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
Re: Chaining IComponentResolvers
Posted by 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!
> > >
> >
> >
>
Re: Chaining IComponentResolvers
Posted by 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
Posted by Al Maw <wi...@almaw.com>.
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!
>