mca blog

update: (moments later...)

i've confirmed that i can use <include href="..."/> within the main XSLT file without any code changes to exyus. that means that it should be possible to build support for a single XSLT file for each resource and even use the include directive for handling calls to the default-space for certain cases.

this is looking like a very good solution!

i've been going on about this in my head for a couple weeks. not really satisfied with the results.

so far, i've been supporting an XSLT document that has a name like this:

get_request_item_xml.xsl

this allows me to create other XSLT documents to fit other needs:

get_response_list_atom.xsl
delete_request_xml.xsl
put_request_atom.xsl


all fine except this gets pretty messy - and fast. adding support for a new document type will ballon the XSL documents in the folder rather quickly. add to that the idea that i want to support a "default" XSL for the most common cases (get_response_list_atom.xsl) and now it's really messy.

at first i thought i'd support a single file for each method/mime type:

get_xml.xsl
get_atom.xsl
get_text.xsl


that works pretty well, but not great. i still have to worry about the list|item issue for GET methods. and support for additional methods (PUT,POST,DELETE) will continue to grow files.

so my next idea was to use a single XSL file for each method - adding support for the mime-types *within* the XSL file using a choose pattern to handle it:

<xsl:param name="method" />
<xsl:param name="format" />
<xsl:param name="list-item" />

<xsl:choose>
  <xsl:when test="$method='get' and $list-item='list'">
  	<xsl:call-template name="get-list" />
  </xsl:when>
  ...
</xsl:choose>

<xsl:template name="get-list">
  <xsl:choose>
    <xsl:when test="$format='atom'">
      <xsl:call-template name="get-list-atom" />
    </xsl:when>
    ...
  </xsl:choose>
</xsl:template>

the drawbacks here are: 1) the XSL file can get pretty long - esp. if you want to support lots of formats. but you can mitigate that by using import and include elements in the document. 2) if you want to support 'fallbacks' for one of the formats (atom is a good example), this single-document approach kinda stinks. there's no clear way to fall back to an existing document for just one of the formats. it's possible that you can use an include/import to solve that problem, too. i need to look into that possibility.

if i can solve the fallback issue with include/import, then the second approach seems the best. that means the compiled code only needs to know about a single document for the resource and the rest can be handled within the XSLT document itself. that is the shortest code path, too.

btw - i will still need to support XSD files for the input and maybe even the query string arguments. that's not a killer, but it is some additional work. the arguments will be the same regardless of the mime-type. however the XSD validation will differ. unless i use an additional XSLT round to pre-convert the incoming into a standardized XML format - not a back idea considering i'll want to support microformats, too (notoriously *bad* validation-wise).