For objects that render text data, XSLT could be used to introduce a bit more flexibility into the current WebView mechanism. This could be used in the following ways:
- For the "default" rendering of an object (the rendering used when the object is addressed), an XML representation could be generated by the WebView.
- An XSL translation could be selected based on:
- Mime type
- Type of requesting client
- Standalone vs. inlined
- A standard mechanism for viewing/editing/etc... these standard sheets could be designed
- For alternate views of an object, a new kind of object could be added that simply provided an alternate view of one or more objects.
- Need to consider header-generation issues if aggregation is to be supported. (This probably reduces to "in-line XML" vs "standalone XML".)
- For a given request, there are a number of objects that could provide XSL translation data. A reasonable ordering might be:
- The container objects for the requested object. Note that in the case of an object embedded in another object, this would need to be based on the path to the object that the browser (user) requested, and not the path to the embedded object.
- Searching should begin with the immediate parent of the requested object, and proceed up the hierarchy from there.
- The incremental cost for this search should be minimal, since all of the parent objects will have already been retrieved. In the normal case, the search will just involve a series of
instanceof checks to look for containers that might provide XSLT data.
- XSLT provider information "attached" to the object via properties stored in the
EmbeddedObjectDescriptor. While details of this approach have not been designed, the idea would be to support a general mechanism for attaching alternate views to an object in a way that was independent of the object's implementation. (E.g., for cases where the object did not support any kind of view modification.)
- The object's default XSLT.
Issues:
- Arbitrary HTML tags included in object data will need to be escaped when generating XML representations.
- This can be handled by including text that could contain HTML in XML
CDATA elements, and then specifying "disable-output-escaping="yes"" in XSLT value-of elements.
- Selection of XSLT data will require information about the context of the request that is not currently available in the system. (Specifically, the original path/url of the request and inline vs. standalone information.) Rather than (further) cluttering the API, this may be a good time to introduce a
WebRequestContext object, roughly analagous to ComponentContext, that encapsulates information about a request:
- The
ReplicatedObjectClient that provides login information
- The
EmbeddedObjectPath for the requested object
- The requested mime-type for the object
- A flag indicating inline vs. standalone
- The URL and
EmbeddedObjectPath for the object that was originally requested, in the case of requests for embedded content.
- The
PropertiesSource object that encapsulates other request parameters
Based on a request for a way to embed RSS feeds, a general XMLFeed object, with support for XSL translations, might be a good way to experiment with uses of XSL in general. (E.g., it may be possible to add XML renderings of other objects, then use the XMLFeed object to experiment with some of the issues described above.)
The XMLFeed object should have:
- A feed location, probably a URL but conceiviably a path to a bridge object
- Cache settings for feed data
- Should cache be per-XMLFeed, or per feed URL?
- Setting for output mime-type, defaulting to html (or xhtml?)
- Setting for XSL stylesheet:
- "Built-in" sheets for RSS
- Sheets from a template directory
- URL or path to a sheet
|