It is used for every url we generated and that url is when it comes back in mapped again on that strategy by the
key where it sits in.
So if those 2 keys are not an exact match everything goes completely wrong.
for our package mounting, bookmarkable class or shared resource mounting we have it under control how to call the mount() method
but from the outside it is just very strange and error prone.
So the thing to do is do remove the path out of the mount. Or don't use that hashmap when looking up but ask it for every
coding strategy. So don't do this:
for (final Iterator it = mountsOnPath.entrySet ().iterator(); it.hasNext();)
{
final Map.Entry entry = (Entry)it.next();
final String key = (String)entry.getKey();
if (path.startsWith(key))
{
return (IRequestTargetUrlCodingStrategy)entry.getValue();
}
}
but
for (final Iterator it = mountsOnPath.values().iterator(); it.hasNext();)
{
if( (IRequestTargetUrlCodingStrategy)it.next()).match(path);)
{
return strategy
}
}
just as matches the other way works (if we have a request target)
johan
On 4/18/06, Eelco Hillenius
<[EMAIL PROTECTED]> wrote:
IRequestTargetUrlCodingStrategy was meant to be an internal class at
first, but later on public final void mount(String path,
IRequestTargetUrlCodingStrategy encoder) was added to WebApplication,
making things like your example a bit more likely.
I'm not sure whether a coding strategy should be bound to a path like
that. It's something to consider, but certainly not for 1.2.
Eelco
On 4/18/06, Johan Compagner < [EMAIL PROTECTED]> wrote:
> What happens if i do this:
>
> application.mount("/path1", new
> BookmarkablePageRequestTargetUrlCodingStrategy("/path2",
> MyClass.class , null))
>
> Then the 2 paths are out of sync?
>
> shouldn't IRequestTargetUrlCodingStrategy have a getPath() method and every
> mount method with a IRequestTargetUrlCodingStrategy
> shouldn't have a path string. But get the path from the
> IRequestTargetUrlCodingStrategy itself.
>
> johan
>
>
>
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
