XSD -> JavaScript/JSON .. any interest?

Jun 5, 2013 at 6:00 PM
I've written a little extension that will take an XSD and convert to JavaScript object (if anyone's doing HTML 5 style development).. We use object state, so it's important that the server side (C#) property classes are in sync with what's being passed back and forth (JSON)... this helps limit the amount of writing a client developer needs to do and gives them the info they need for databinding and what's expected etc. Not sure if this is something to include as a plug-in here, or just keep it local to what we want... I guess if there's interest...
Jun 6, 2013 at 2:51 PM
+1 for interest in this extension; I've often thought of building one as well but just the time to do so (or enough need) just hasn't happened yet.
Jun 6, 2013 at 5:03 PM
The trouble I’m having is just in the proper incorporation of it into the XSD framework. Sure, what I have now is sufficient for our needs, but to include that into the ‘global’ XSD code base, I’m not entirely sure what the proper way would be. The generation of the JavaScript is fairly basic, we don’t overly need to worry about super details… I ride on the coat tails of the CSharp codedom (since that’s what we work in)… I created a JavaScriptExtension derivied from CodeExtension and overrode the Process method… From there we have all the classes and properties (along with other info) generated from the initial XSD. Currently in the Process method is where I write out the .JS file since everything after the Process call is around generating the .CS file (which in the case we don’t care about… but I’m thinking of adding an extra selection with the CS generation that will automatically create the .JS file as well, as another way of doing it)…Here’s a sample of what a generated .JS file looks like:
function value() {
    this.id = "";//Object Type: 'System.String'
    this.Value = "";//Object Type: 'System.String'

}

function ICMWebService_State() {
    this.headerinfo = {};//Object Type: 'headerinfo_type'
    this.method_name = {};//Object Type: 'icmwebservice_methods'
    this.icm_version_info = "";//Object Type: 'System.String'

}

function headerinfo_type() {
    this.meta_properties = [];//Object Type: 'dynamic_properties' - This is an Array objects
    this.return_messages = {};//Object Type: 'return_messages_root'

}

function dynamic_properties() {
    this.value = [];//Object Type: 'value' - This is an Array objects
    this.id = "";//Object Type: 'System.String'
    this.desc = "";//Object Type: 'System.String'
    this.prop_value = "";//Object Type: 'System.String'

}

function return_messages_root() {
    this.msg_info = [];//Object Type: 'msg_info_root' - This is an Array objects

}

function msg_info_root() {
    this.type = {};//Object Type: 'msg_type_enum'
    this.message = "";//Object Type: 'System.String'
    this.utctime = {};//Object Type: 'System.DateTime'
    this.localtime = {};//Object Type: 'System.DateTime'
    this.msg_trans_id = {};//Object Type: 'System.Int32'
    this.binarydata_info = {};//Object Type: 'msg_info_rootBinarydata_info'

}

var msg_type_enum = {
    Emergency: "Emergency",
    Alert: "Alert",
    Critical: "Critical",
    Error: "Error",
    Warning: "Warning",
    Notice: "Notice",
    Informational: "Informational",
    Debug: "Debug"

}

function msg_info_rootBinarydata_info() {
    this.ref_id = "";//Object Type: 'System.String'

}

var icmwebservice_methods = {
    ICMWSProvider_GetICMVersionInfo: "ICMWSProvider_GetICMVersionInfo"

}
Jun 6, 2013 at 5:52 PM
So generating script stuff varies a bit different from native code generation…I don’t want to modify what’s in place already (in regards to the XSD work flow ) so what I’m thinking is this…

I create a new property called ‘TargetScriptFramework’… It’s placed after TargetFramework in the property grid… Default is ‘None’. If the user selects a supported scripting type, after the TargetFramework is generated, it’ll also call into the given ScriptCodeExtension object which does whatever generation it needs to do and returns….