August 23
I've uploaded a newer, less buggy build of Xsltx to Skydrive that also has built in support for compiling different 'views' for a control, set at design time. There's a simple use of views in the samples if you want to have a look.
August 17
We've found quite a few bugs in the last build of Xsltx and we're busy fixing them - having an increasing number of uses and test cases for this is helping drive out the errors and omissions as well as the plain simple stupid bugs :). I'll post another build next week when it seems more stable. In the meantime, if you use it don't trust it - just for playing and feedback atm.
August 14
I had feedback recently from a few people I know who are interested in Xsltx, e.g. 'The Kid' and Rich Kennedy. Two big things they wanted adding were:
- The ability to override and change the rendering at runtime, e.g. by setting a control property. To be used typically in webpart scenarios where solution designers want to easily prototype changes and minor improvements to the UX etc. without needing any recompilation.
- The ability to update the original XML without having to write any code, e.g. by declaratively relating a control property to an XML node described by an XPath expression.
I've now done both of these and they make it a lot more useful - (2) in particular is really cool as you can now build a form using Xsltx and server controls without needing to write any code apart from to load and save the XML. Looking forwards other changes that may get done include:
- Optional validation of the source data and any updates to it against a schema.
- Some kind of (extensible / replaceable) hash based check on the XML data when updating it to ensure it hasn't changed since the data was rendered.
- A provider / datasource model for the loading and saving of the data to avoid needing to code this. Obvious data sources are databases (via DataSets and SqlAdapters or similar), web services and XML files stored in SharePoint libraries.
- Integration with SharePoint for the InfoPath style scenario of creating, storing and editing XML forms in SharePoint. We love InfoPath for this scenario but sometimes as developers it just doesn't give us the control we'd like. Xsltx gives us an option where we don't have to go fully bespoke if InfoPath doesn't fit.
- A wizard to convert an InfoPath form to Xsltx. This would probably be lossy as script and code behind forms wouldn't migrate easily, but it would give you a quick design surface with InfoPath to accelerate initially building some of the Xsl(tx).
- Finally finishing the VS integration to support new file wizards, etc. If only VS was easier to customise...
Files posted on skydrive. Let me know if you want any other features or want some help.
Tools 
