Nov 16th, 2004, 04:15 PM
JSPs design-time v. runtime location and WYSIWYG editing
At runtime, URLs in a page reflect an address relative to the URL that was used to call the servlet, but at design time, these pages are located elsewhere (e.g., under WEB-INF/jsp). So for example, the stylesheet references will be incorrect at design time.
I can't think of a way around this except to make the runtime and design time locations match. The drawback is that then the pages are addressable from the user's browser. Anybody else having this problem? Thanks.
Nov 17th, 2004, 01:36 AM
.When you edit a page using a wysiwyg app, you don't know in advance what will be the url used to call you jsp. I wouldn't make the assumption that the jsp structure will match the one of the calling url (you would somewhat break the ability for a new controller/url to reuse a common jsp for instance).
Still to keep outgoing url from your jsp page valid, you need to control where you are seen from the client, as to use relative uri; or eventually you may use absolute url but you're breaking the context independance of your webapp.
There is a third way.
Depending on the view technology (jtsl provides it), you can wrap your url in a method (namely c:url for jstl) which takes an "absolute uri" from the start of your webapp and prepend, at runtime, the context in which you are located. This way you don't have to worry where you were called, you know your image location is in /img, use <img src="<c:url value="/img/header.png" />" /> and you're done.
This is a bit romanced but this is how a lived it recently :wink:
Nov 17th, 2004, 09:17 AM
Hmm...sounds like your are giving me the answer to a problem I hadn't thought of: calling the same view from multiple URLs. However, c:url doesn't solve the original problem, because the WYSIWYG tool won't be able to parse it at design time. Actually just using the absolute URL would work, but as you say it breaks context independence, which in this case is critical because a JRun bug requires a non-root context path and I don't want to hardcode it in there.
Another problem is that DreamWeaver doesn't actually parse third-party tags all that well, even though it's supposed to, so perhaps designer independence isn't really possible without going to something like XMLC.