Hi Kevin,
thanks that was very very helpfull indeed! It's working, thanks.
One more question in
XMLHelperImpl.save()
public void save(XMLDocument xmlDocument, Result outputResult, Object options)
throws IOException {
options = checkSetOptions(options);
if (outputResult instanceof DOMResult) {
((XMLDocumentImpl)xmlDocument).save(((DOMResult)outputResult).getNode(),
options);
} else if (outputResult instanceof SAXResult) {
throw new UnsupportedOperationException();
---
when will this be "supported", because I need to read the result of the save
into a JDOMResult, which is a sub-class of SAXResult :-( ?
I can certainly workaround this but that is not efficient to use DOM!
---
} else if (outputResult instanceof StreamResult) {
save(xmlDocument, ((StreamResult)outputResult).getOutputStream(),
options);
} else {
throw new UnsupportedOperationException();
}
}
Thanks, Peter
kelvin goodson wrote:
> I think what you are missing is a declaration of a global element in your
> schema, so if you had something like
>
> <xsd:element name="datasource" type="tns:datasource"/>
>
> then you will be able to get a non-null response from
> Property prop = scope.getXSDHelper().getGlobalProperty(NS_CODA,"datasource",
> true);
>
> You can then call content.setList(prop, list); // using Property based
> setter, not string based
>
> That should get you going.
>
> Alternatively you could do
>
> List list = content.getList(prop)
> then just add DataObjects to list and they will automatically be contained
> in content.
>
> or repeated call
> content.createDataObject(prop);
> followed by content.getList(prop)
>
>
> The problem with the way you are doing it is this -- when you are doing the
> content.setList("datasource", thelist)
>
> the namespace of the property "datasource" is not known. If the Type of the
> content DataObject had a defined property called "datasource" then you could
> just look up the Type of the "datasource" property, but it doesn't, we are
> dealing with open content here.
>
> There may be many "datasource" open content properties registered in
> different namespaces or there may be none, but the runtime can't make
> assumptions about which one to use, and, because the Type of content is
> open, the runtime therefore creates an "on the fly" property "datasource"
> in the no-namespace, and tries to infer it's type from the value passed
> in. I think what is then happening is that the list object that you passed
> in, when serialized, has a sequence of data objects that are not part of
> the containment hierarchy of the data graph, which is not permissable,
> hence the serialization failure.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
