Client-side XML editing w/ DataSources?

[rsinkwitz]

Hi, I have a large XML with XSD description and have to provide editing screens for the different portions. I have the XML client-side in a String variable and can convert to/from DOM with GWT. The XML contains repeating parts and I want to have client-side datasources with full CRUD for those. My questions:
1) Can XmlTools.loadSchema help me with DataSource definition?
2) What are the data source names for the internal complexTypes? Can those be enumerated? How do I distinguish two elements with the same name, but different parent elements?
3) Can the WSDL support or XmlSerialize help me with the CRUD implementation?

Thanks for your help

I'm using smartgwtpower-3.1p (SmartClient: v8.3p_2013-01-28/PowerEdition Deployment (built 2013-01-28))

[Isomorphic]

loadXMLSchema() will give you a SchemaSet object and the loadXMLSchema Javadoc explains what happens to the type definitions. Types in a SchemaSet cannot currently be enumerated, and if there's a name collision, you wouldn't be able to find this out.

If you don't have a WSDL service, the WSDL support does not apply.

If you are trying to view just parts of this document while taking advantage of the browser's ability to store huge XML documents in memory more compactly than, say, a List of Records representation, then you should build a dataProtocol:clientCustom DataSource that, in response to a fetch request, extracts bits of the DOM and converts them to Records (you could use DataSource.recordsFromXML).

Yes, xmlSerialize() could be used to produce XML that could be re-inserted into the original document.

[rsinkwitz]

Examples?

Thanks a lot, that makes things very clear.

1. However, it seems that the data sources defined by XmlTools.loadSchema only include elements form the next level, not further down. I was hoping it would pick all leaf elements (and only those) with corresponding ValueXPath settings which it does not. My XML is not unambiguous on subelements of different record types, so I cannot further dive down via extra data source definitions. I will probably need to repeat the XSD in Java code to get the "all leaf-nodes, only" data sources I need.

2. I couldn't get DataSource.recordsFromXML to work, are there samples?

[Isomorphic]

1. Nested structures are represented by a series of nested DataSources - a DataSourceField can be of DataSource type instead of just a simpleType, just like how in XML Schema, an element can be of simple or complexType.

2. There's not a sample of using this API, but if post code, Isomorphic or a community member may be able to point out issues.

[rsinkwitz]

Flattening Data Sources of XML branches

Thanks, that helped. I noticed, that DataSourceField.getType() returns null for DataSource-type fields. For sub-datasources there is getTypeAsDataSource(), how about SimpleType cases?

I have now adoped an approach, were I recursively navigate those nested DataSources and create a new flat DataSource by copying the leaf-node DataSourceFields, setting valueXPath to read/write hierarchical XML. There are some nested shared DateSources where I needed to clone/rename fields. I copy the field with this JS code:
var outObj = {}; for ( var prop in inObj) { outObj[prop] = inObj[prop]; } return outObj;
then setting setting new "name" and "valueXPath" on the copy.
1. Is the copy "deep" enough?
2. Why do I loose validation on the renamed fields?

[Isomorphic]

You see like you may be reinventing the DataSource.useFlatFields feature - take a look. This may obviate the need to copy fields.

There's not currently DataSourceField.getTypeAsSimpleType() API, although there probably should be, we'll take a note. It should work to call getAttribute("type"), and pass the resulting String to SimpleType.getType().

[rsinkwitz]

Unfortunately our XML uses shared ComplexTypes in sub-levels, so uniqueness of names as needed for DataSource.useFlatFields is not possible, or?

We have improved our XSD now to avoid duplicate embedded complexTypes. With my JS-copied DataSourceFields, however, it went into an endless loop now somewhere inside ListGrid.setDataSource. I now use Java field-copy code, however it is not clear what data there is to copy. So far I have encountered the following attributes on DataSourceField: mustQualify name title type validators valueMap xmlAttribute xmlMinOccurs xmlRequired xsElementRef
My issues:
a) getValueMap crashes internally, because the content is a String array (solved partially, see below).
b) mustQualify is not accessible -- is it needed?
c) validation through SimpleType on attributes seems to be missing

Here is my current DataSourceField copy code FYI:

DataSourceField nf = new DataSourceField();
nf.setName(f.getName());
nf.setTitle(f.getTitle());
nf.setXmlAttribute(f.getXmlAttribute());
nf.setRequired(f.getRequired());
nf.setValidators(f.getValidators());

// type
FieldType type = f.getType();
if (type != null) {
	nf.setType(type);
} else {
	String strType = f.getAttributeAsString("type");
	if (strType != null) {
		nf.setType(SimpleType.getType(strType));
	}
}

// value map as string array
String[] valueMap = f.getAttributeAsStringArray("valueMap");
// TODO support map type too
if (valueMap != null) {
	nf.setValueMap(valueMap);
	nf.setAttribute("mustQualify", f.getAttributeAsObject("mustQualify"));
}

[Isomorphic]

useFlatFields requires uniqueness of names only for fields of SimpleType. Intervening complexType declarations need not have unique names.

So again, it doesn't look like copying of fields should be necessary, but if it were, you should ignore attributes such as mustQualify or xsElementRef, which are internal details needed for serialization of XML that conforms to the XSD. You would basically want name, type, valueMap and required.

And yes, valueMaps can validly be specified as a String Array, so your call there is correct.