My initial thought is that you should enforce *one* path
hierarchy. That is, all HTML files must either go in
/WebApp/WEB-INF/classes/* or in /* but not both. This would solve your
inability to differentiate between /Home.html that might lie in two
places:
/WebApp/WEB-INF/classes/Home.html, and
/Home.html
It seems to me that Wicket prefers the first method, so fine...
just tell people if you use Wicket, all your resources must be found
under WEB-INF/classes.
The only downside to this approach is that it would be
impossible for one WebApp to refer to resources found on another WebApp
without full qualified paths or maybe some other mechanism (can you do
that with normal JSPs? I forget...). Still, it seems to me that Wicket,
by it nature, strongly discourages stepping outside the hierarchy
anyway so it would be in the nature of what we're trying to push.
Thoughts?
Gili
On Fri, 31 Dec 2004 10:11:27 +0100, Eelco Hillenius wrote:
>Gili, thank you for explaining, but I still do not agree with you.
>
>> So we have:
>>
>> /WebApp - webapplication root path
>> /WebApp/Home.html - Home.html that isn't registered with a
>>Wicket page
>> /WebApp/sub/OtherPage1.html - some HTML page
>> /WebApp/sub/Home.html - HTML page registered with a Wicket page
>> /WebApp/sub/Home.java - Your Wicket Page
>> /WebApp/sub/OtherPage2.html - some HTML page
>>
>>
>Some remarks:
>
>1.This would be an actual layout:
>
>/webapp
>- webapp root path
>/webapp/Home.html -
>static page
>/webapp/WEB-INF/classes/sub/Home.html - Wicket Home.html
>/webapp/WEB-INF/classes/sub/Home.java
>/webapp/WEB-INF/classes/sub/OtherPage1.html
>/webapp/WEB-INF/classes/sub/OtherPage1.java
>/webapp/WEB-INF/classes/sub/OtherPage2.html
>/webapp/WEB-INF/classes/sub/OtherPage2.java
>
>classes could be lib/xxx.jar: as well.
>
> b. The default Wicket way of doing things is to put the HTML in your
>class path. You could do otherwise (like the Hangman example displays),
>but this is not the general rule, and will bite you if you work with
>packaged pages (ie panels and pages that you put in a jar) like I do a lot.
> a. The OtherPage1/2.html in your example actually could never refer
>Wicket pages, as they are not Wicket pages themselves.
>
>> Now you are concerned that it is impossible to refer to
>>/WebApp/Home.html? Let me explain why that isn't a problem.
>>
>> Say you are inside OtherPage1.html,
>>
>> if you have <a href="Home.html"> it'll link to
>>/WebApp/Home.html
>> if you have <a href="sub/Home.html"> it'll link to
>>/WebApp/sub/Home.html
>>
>> Say you are inside OtherPage2.html,
>>
>> if you have <a href="Home.html"> it'll link to
>>/WebApp/sub/Home.html
>> if you have <a href="/WebApp/Home.html"> it'll link to
>>/WebApp/Home.html
>>
>> I hope that clarifies what I mean. The new behavior is
>>identical to the behavior of preexisting HTML links in all cases.
>>
>>Gili
>>
>>
>>
>
>Ok, the above example *could* work if you do this in your application class:
>
>String path = getServletContext().getRealPath("/");
>getSettings().setSourcePath(new Path(new Folder(path)));
>
>And have .java files for OtherPage1/2.
>
>Now,
>
>2. /WebApp/Home.html will not get you to the static Home.html. The web
>application directory is transparant; it is just a trick for servlet
>containers to be able to host more than one web application on one
>instance of that container. So, usually, you would refer to this page
>like: <a href="Home.html">. This conflicts with the link to the package
>local Home.html.
>
>3. I find it a great concern that <a href="Home.html"> in
>OtherPage1.html would refer to the static Home.html - which is in a
>different directory while in OtherPage2.html, it would refer to the
>package local page.
> a. you would have a problem when you decide to refactor (e.g. move
>Home.html to sub2). The implicit references will be harder to find that
>explicit ones.
> b. It is plain ugly and inconsistent that, depending on what is in
>your current directory, you must refer to the static pages in different
>ways (when no package local Home.html exist, you use <a
>href="Home.html">, but if it does exist, you use <a
>href="/WebApp/Home.html">).
> c. This all could not work anyway, as packaged resources would not be
>supported and the web app dir/ web application name is transparent to an
>actual web application.
>
>Regards,
>
> Eelco
>
>
>-------------------------------------------------------
>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
>
-------------------------------------------------------
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
