On Sat, 01 Jan 2005 12:22:00 -0800, Jonathan Locke wrote:
>Gili wrote:
>
>> That's why I've stated before I think we should disallow the
>>ability to store HTML files both under /WebApp/ and
>>/WebApp/WEB-INF/classes/ -- force one or the other. Otherwise it could
>>lead to confusing behavior for the user. If we force all HTML files
>>under a single root path we guarantee consistent behavior and no name
>>collisions.
>>
>>
>sorry, i'm not really following this conversation, but this sounds
>extreme to me.
>if you're forced to put all your HTML files in the classes folders,
>haven't you
>essentially excluded any possibility of integration with anything else?
>also, what
>about sites that are 90% static files? why should those belong in classes?
The problem is that if you have /WebApp/Home.html and
/WebApp/WEB-INF/classes/Home.html and <a href="Home.html"> it is
impossible to know which one you are refering to. That's why I stated
we should resolve the search path.
Now that I think of it, it isn't strictly necessary. What we
can do is use a combination of the CLASSPATH and ResourceLocator. We
state that we resolve resources by searching the CLASSPATH (first match
is used) and ResourceLocator is always found at the front of the
CLASSPATH. This way, if Home.html exists in both paths, and we default
to /WebApp/WEB-INF/classes/ being in the classpath before /WebApp/,
then you can override the behavior and refer to /WebApp/Home.html if
you map it explicitly using ResourceLocator, or use an explicit Link
component in your HTML.
Gili
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
