mca blog

yep - had a brain-bulb last night on my transform/validate patterns. i started creating separate documents for transforming input/output based on HTTP method (GET,PUT,POST,DELETE) and then modified them to include media type (XML,ATOM,RSS,etc.). i than needed to support transformations based on 'mode' of the stream (Request/Response). also, the GET word really has two possible flavors: GET-list and GET-item. finally, i wanted to support a 'fallback-to-default' pattern that would allow the simplest of transformation/validation patterns 'just work' without an authoring at all (Atom will work like this as will most POX situations). all pretty complex.

but now i think i have it. i do two key things. first, a supply a param to the transforms that includes the 'mode' (Request/Response) of the call and a param for the flavor of the GET (list|item). i already include the method and lal other pertinent state data for the transaction. the second thing is to conflate everything for an HTTP Method into a single file (GET,PUT,POST,DELETE) per media type. now i will have files like get-atom.xsl, put-atom.xsl, post-atom.xsl, etc. not too bad.

i was worried that this would result in large files. no so fun to work with. this is esp. true for the ones that support T-SQL calls. GETs can be pretty involved if you support various query parameters, too. but this morning i realized that i can break these up using import and include keywords from XML/XSD. that means authors can control the size of the files, re-use parts, etc. without the exyus engine having to deal with the details. now that's smart.

i hope to have this in place by the end of the day.