DataSource and xml schema

[MarkA]

Have a tricky question I'd like to ask. We're currently using Smart GWT version 2.03 and we're using DataSources generated from XML Schemas to create a dynamic front-end. The front-end created this way was good for the last 8 months, but now we want it to do more. We want to however continue using our XML Schemas and don't want to use ds.xml. Our plan then is to use the special xml <appinfo> fields to pass in our own custom instructions that we would parse ourselves and then use to modify the DataSource, such as change a text field into a text area field.

Here comes the problem. We currently loading our xml schema into a DataSource using the Smart GWT SchemaSet object. So we are automatically given a DataSource from our schema. Now if we were to embed some <appinfo> tags into our schema, would there be anyway to query this data while it is in DataSource form or is all this information lost when it's converted from the Schema to the DataSource form?

If the data is lost in the conversion then can anyone give a quick example on how we can load the schema first as a Schema object and THEN load it into a DataSource? I've been reading up on the DataSource for a while (quick guide, javadoc, etc) but I haven't found any examples of how load a schema into a DataSource.

[Isomorphic]

When loading XML schema we don't do anything with attributes that don't map to existing DataSource properties.

There's no way to load anything less than an .xsd file as a SchemaSet because no portion of an XSD file makes sense on it's own. All the definitions are interconnected.

There are a few possibilities for how to proceed:

1. load the XSD as just XML (XMLTools.loadXML) and use XPath to find the information you need, then apply it to the DataSources retrieved from the SchemaSet

2. use the schemaTranslator.xsl directly with XMLtools.transformNodes and modify the XML output before it gets turned into a SchemaSet.

3. sponsor some kind of enhancement to make this simpler. For example, a feature that causes certain namespace-prefixed extension properties to be transformed into same-named DataSource / DataSourceField properties when discovered in XSD.

[MarkA]

I seem unable to find/use the functions you're talking about.

I don't see loadXML or tranformNodes in XMLTools
http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/data/XMLTools.html#selectNodes%28java.lang.Object,%20java.lang.String%29

Is there another XMLTools in another package that I'm not aware of?

[Isomorphic]

You're correct, these are actually only available by calling down to the underlying SmartClient APIs via JSNI.

For #1, core GWT has an XMLParser API you could use instead.

For #2 if you Google "GWT XSLT" it looks like there may be projects that attempt to provide an API similar to transformNodes().

[MarkA]

So we've been testing out concept number 1, load the xsd as xml and apply it to the DataSource. We've found out that to get this to work we had to do callback chaining in the client. We don't really like this option and instead we're thinking about trying to do all the modifications in the server first and then send the data.

This new server approach unfortunately has created a new problem. How do we create a SchemaSet object in the server? SchemaSet is constructed using a JavascriptObject and a JavascriptObject cannot be instantiated.

[Isomorphic]

There's not currently a way to do this server-side other than #2 (direct use of the imperfectly documented XML). We'd not sure how callback chaining came into your implementation of #1, but even if necessary, it's not really a big deal, and that's what we'd recommend doing.

[MarkA]

I had a feeling it wasn't possible : /

The call back chaining in #1 is because we needed to load the schemaSet (XMLTools callback) and then load the schema as xml (another XMLTools callback). So we had to chain the callbacks and then once we had both the schemaSet and the schemaXML we had to pass both into a function that would do the blending.

We avoided #2, use the schemaTranslator.xsl, because we don't want to start changing/overriding the internals of the schemaTranslator.xsl, because it would result in additional maintenance issues when Isomorphic changes it at a later date.

So in the end, due to time constraints, we dropped the server approach and went back to #1.