View System Documentation - Resource Addressing
HTML Relative VS. Absolute URL Addressing
Relative URL addressing provides a way to address a resource relative to the current resource's path without having to specify the protocol, server address, port, application context, and directory path information. This helps page maintenance as the links are not dependent on the applications deployed directory or how the web server has this application mapped. Most web developers (especially dynamically created content JSP and ASP developers) use relative addressing as much as possible to not only simplify page link URLs but also to simplify image links, stylesheet links, and script links. The majority of all local application links contained within the PAGE XML pages should use absolute resource addressing. This is because unless the page is using the same URL mapping that goes to the same Java servlet controller or which points to the same area the resource will not be located or delivered correctly. Because absolute addressing is very site or deployment specific and thus difficult to maintain a special mechanism has been built into the "page.xslt" templates. This mechanism uses the "ibis:" namespace for link type attributes (src='', action='', href=''). When the template processes these type attributes it prefixes the attribute's resource link value with the "WebAppURLContextPrefix" parameter. This allows the link to be an absolute application link without having to know the application's context address. See the Addressing page for more specific information. Listed below are some examples.
Given:
WebAppURLContextPrefix Parameter = "http://server/app_context/"
External link to Utah's "Disease Fact Sheets":
<a href="http://health.utah.gov/epi/fact_sheets/Default.htm">
Utah's Disease Fact Sheets Page
</a>
==> http://health.utah.gov/epi/fact_sheets/Default.htm
Internal application link to the "IBIS-PH Acknowledgments" page:
<a ibis:href="home/Acknowledgments.html">
IBIS-PH Acknowledgments Page
</a>
==> http://server/app_context/home/Acknowledgments.html
Internal application link to the "IBIS-PH Acknowledgments" page
when on the IBIS-PH Welcome Page. This shows relative addressing
which is possible since both are based on the same path (home):
<a href="Acknowledgments.html">IBIS-PH Acknowledgments Page</a>
==> [http://server/app_context/home/]Acknowledgments.html
where the browser supplies the implied relative address
of: http://server/app_context/home/
Internal application link to an image file:
<img src="contentfile/image/thoth.gif"/>
==> http://server/app_context/image/thoth.gif
IMPORTANT: If the page contains any "ibis:" namespace type attributes then
the 'xmlns:ibis="http://www.ibisph.org"' must be applied the the main PAGE,
CONTENT, or any parent containing element. Example:
<CONTENT
xmlns:ibis="http://www.ibisph.org">HTML Relative VS. Explicit URL Addressing
Relative URL addressing provides a way to address a resource relative to the current resource's path without having to specify the protocol, server address, port, application context, and directory path information. This helps page maintenance as the links are not dependent on the applications deployed directory or how the web server has this application mapped. Most web developers (especially dynamically created content JSP and ASP developers) use relative addressing as much as possible to not only simplify page link URLs but also to simplify image links, stylesheet links, and script links. The IBIS-PH View System has three ways to deliver content.- Straight static content e.g. normal web server
- Using the generic "view" servlet controller where both the XML and XSLT are specified as a query string as part of the request's URL.
- Using a mapped resource path to Java servlet controller. This involves a Java servlet controller where the XML and XSLT are specified as part of the path and the controller then determines the real path based on properties that are specified in the system's configuration and property files.
The IBIS-PH View System's resources typically do not lend themselves to be addressed relatively. This is because of the URL path mapping that is implemented. If using the "view" servlet controller where both the XML and XSLT are specified as part of the URL then relative addressing can be used to reference images, form actions (as page references are not of the form xyz.html they look like "view?xslt=some/path/some_file.xslt&xml=some/other/path/some_xml_file.xml". However, if the URL mapping system is used, then those resources that are addressed using the same URL path can be addressed using a relative address (just like they would be in a normal HTML static page environment). This latter URL Mapping solution involves a special Java servlet controller where the XML and XSLT are specified as part of the path and the controller then determines the real path based on properties that are specified in the system's configuration and property files. To help with not having to hard code the system's URL a special feature is built into the "page.xslt" (described above). This allows the usage of an "ibis:" namespace on link type element attributes. Those attributes can then be freed of the deployment explicit URL addressing and can use a semi relative address. If the page is to be used in either way of if the developer is unsure on how the page is to be used then it is advised to use the "ibis:" namespace prefix on all the page's link element attributes (href, src, and action). on the To be 100% safe The "page.xslt" has been programmed to Example of syntax and usage: ibis namespace for relative vs absolute need to discuss deployments and if a page is same level it is okay but otherwise it is not. supported attributes: href, src, action URL NOTE: This template contains a special way to handle IBIS type URLs. Instead of hard coding the link to include the application context and path, a relative type path can be used with an "ibis:" namespace. This causes the web app context prefix to be added to the resource path so that the path is free of context deployment paths. If the link is within the same 'folder' (as defined in with the resource mapping), then the 'ibis:' is not needed. However, if it is NOT, then it should be used. An example is the 'home/ContentUsage.html' page referencing a graphic image 'image/UDOH.gif'. If the link is coded using relative addressing and the system is deployed to the webapp context of 'ibisph-view' then this link will not work because the server will look for the image with a path of: 'ibisph-view/home/image/UDOH.gif'. To work, the link would have to be coded as '/ibisph-view/image/UDOH.gif' but what happens if this save system is deployed as the root application. Then the link would have to be coded as '/image/UDOH.gif' etc. The processing of the link by this template automatically adds the appropriate webapp content prefix so that the resources can be relatively addressed. Of course if a relative address is really wanted then simply skip placing the 'ibis:' namespace prefix to the link's attribute.
see: http://www.ietf.org/rfc/rfc1808.txt, http://www.w3.org/Addressing/ preview uses xslt general localhost view? testing where this file is in the dir, the root is set to testing using a XML XSLT page transformation controller how to make it look like a a static page - deployment ready. hook it into word about format general see the html page design word about css - general see the html page design word about xslt - page.xslt see xslt design Xinclude support only if the xslt is modified or the java controller implanted