So lets revisit the issue: short of having to redeploy the entire
application if any of its files are changed, what is the shortfall of
packaging everything within the JAR? And now that I think about it, your
resources don't necessarily need to be inside a JAR. I keep them
normally expanded in WEB-INF/classes so there should be nothing
preventing me from replacing files are runtime without a redeploy, right?
We should keep on investigating crawler-safe URL options but "worse
case scenerio" if there is no cleaner solution I am +1 for this change
anyway. Crawler-safe URLs are far more important to me than the
inconvience of having to redeploy my application on changes.
Correct me if I'm wrong, but in production machines you have to
redeploy on changes anyway because "watch resources for changes" should
be disabled on those machines for performance reasons (or so the Tomcat
documentation says).
Besides, when you think about it, it makes sense why JSP have
context-path issues like this and we should probably have them too.
Package-relative resources breed better application modularity. If you
want to share resources you could always create your own package
"shared" and reference resources relative to that. <shrug>
Gili
Eelco Hillenius wrote:
Yes, but naturally everything on your pages would have to be packaged.
Eelco
Gili wrote:
If we use packaged CSS (i.e. CSS contributions from Wicket 1.1)
this problem will go away, right?
Gili
Eelco Hillenius wrote:
Just play around with the attachement, and you'll see soon enough
what I mean.
Basically, if your url is http://server/ctx/webapp/pages/page1 where
webapp is your application root (with WEB-INF and e.g. style.css), a
reference on that page one will only work with either an absolute
path or ../../style.css
This is a common problem when using plain JSP, and model 2
frameworks, which is why you need to use request.contextPath all over
the place in those apps. It is nice with Wicket that you don't have
to use that, but if you want to use /-es you also have to fix the
path problem.
Eelco
Gili wrote:
Eelco,
I'm also +1 for replacing the built-in URL architecture with a
crawler safe one if possible. This sort of stuff should just work
out-of-the-box without any special configuration.
I don't understand what you mentioned about the slashes
upsetting the CSS engine. Can you please elaborate?
Thanks,
Gili
Eelco Hillenius wrote:
This has been a question on the list several times: how do I
rewrite my
URLs (so that they are crawler friendly).
I worked out an example (patched version of Linkomatic) of how this
could be done and attached it to RFE at:
https://sourceforge.net/tracker/index.php?func=detail&aid=1209464&group_id=119783&atid=684978
HOWEVER... it is far for complete, and there are some obvious
issues with it (I translate to use
slashes like pages/foo/bar/ which upsets resources like .css
references
as they think they reside in another directory then).
So, I won't support this (no time, sorry) but I thought to give
some of
you at least an idea of how to start fixing this. For 1.1 ofcourse, it
would be great to have a complete implementation, which could maybe
even
replace the current non-crawler-friendly urls we have now. That is, as
long as it doesn't make Wicket less easy to use.
Hope you'll find it of any use,
Eelco
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit
http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit
http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit
http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit
http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
