Announcement

**Isomorphic** · 24 Nov 2010, 10:43

If you have the ability to integrate at another layer (say, with a Java Beans API), do that instead. This is a messy integration point because there's no schema for how XML messages should be formed. Instead it sounds as if the ultimate data provider is expecting you to hold onto the original XML document and submit the whole thing, even if parts of it weren't modified?

If so, you can do this, and you're using most of the right APIs, except:

1. your XPaths aren't quite right, for example, "artist[@id]" selects an artist element with a non-null id attribute, not the id attribute itself

2. it's expected that if an element is not simple (has attributes or subelements), in the absence of an XPath it will be turned into a JavaScript object containing it's attributes and subelements. There's no other choice except to drop data

As far as applying updates to the target data, if this is a relatively complex XML document and you're only editing certain properties from it, the best approach might be to store it in the session and apply updates selectively when "update" et al requests come in, rather than trying to round-trip all data to the browser and rebuild the document from scratch.

**firebet** · 24 Nov 2010, 11:29

Thanks for responding so quickly.

We do have a schema for the XML and we use JAXB in other areas of the app to marshal/unmarshal the XML and modify data in the document, but as far as I know, we can't pass JAXB objects to the client because they aren't regular POJOs? (Hence I was trying this approach for the client).

I could write new POJOs and copy the properties from the JAXB objects and pass them to the client, but it's an extra conversion that I was hoping might not be necessary?

In terms of the xpath, what is the correct way to select the artist id attribute? artist/@id ???

When you say "in the absence of an xpath", are you talking about a valueXPath in the DataSource config?

I'd hoped to be able to create a DataSource config something like:

Code:

<DataSource  
     ID="exampleDataSource"  
     serverConstructor="com.nielsen.smartgwt.test.server.ExampleDataSource"
     recordXPath="/product"
>
    <fields>
        <field name="artistID" type="integer" valueXPath="artist/@id" />
        <field name="artistSource" type="text" valueXPath="artist/@source" />
        <field name="artist" type="text" valueXPath="artist" />
        <field name="title" title="Title" type="text" valueXPath="title" />
    </fields>
</DataSource>

which could map between the expected xml elements in the Document and the form widgets. Then when the user selects to save the form/grid, the document is rebuilt on the server-side and saved back to the db?

If I had the correct xpath notation in the DataSource config, could I get the conversion to create JSON like:
artist:"Artist Name"
artistID:"101"
artistSource:"devAdmin" ?

But I'm still unsure how I go about getting the text value from a non-simple element types because, as you say, it drops the data during conversion. How do I get it to keep the text data as a JSON field?
Thanks.

**Isomorphic** · 24 Nov 2010, 12:03

We do have a schema for the XML and we use JAXB in other areas of the app to marshal/unmarshal the XML and modify data in the document, but as far as I know, we can't pass JAXB objects to the client because they aren't regular POJOs? (Hence I was trying this approach for the client).

If they have getters and setters that follow the Java Beans convention (type getBlah/setBlah(type)) they'll work with DataSources and there's no need to create a separate "DTO" (Data Transfer Object) POJO. See "Returning Data" in the QuickStart Guide chapter on the Server Framework for more information.

In terms of the xpath, what is the correct way to select the artist id attribute? artist/@id ???

As mentioned above, you can probably work directly with your JAXB beans, which is much simpler. But yes, the XPath would be either that or artist@id - but the best thing to check is the JXPath reference, that's what server-side valueXPath processing uses. This will also show you how to write an XPath that extracts the text content of a complex element.

When you say "in the absence of an xpath", are you talking about a valueXPath in the DataSource config?

Right.

If I had the correct xpath notation in the DataSource config, could I get the conversion to create JSON like:
artist:"Artist Name"
artistID:"101"
artistSource:"devAdmin" ?

Yes.

**firebet** · 25 Nov 2010, 04:56

Thanks Isomorphic, I really appreciate the help.

Ok, I have now implemented it using the JAXB beans and the valueXPath statements now work the way I expect. My JAXB 'Product' class has an 'Artist' object which has a 'value' attribute, so valueXPath="artist/value" now gets me "Artist Name". (I added productID to check the top-level "id" attribute could be referenced, and it worked too).

Code:

<DataSource  
     ID="exampleDataSource"  
     serverConstructor="com.nielsen.smartgwt.test.server.ExampleDataSource"
     mappedBeanClass="com.nielsen.smartgwt.test.jaxb.Product"
 >
    <fields>
        <field name="productID" type="integer" valueXPath="@id" />
        <field name="artistID" type="integer" valueXPath="artist/@id" />
        <field name="artistSource" type="text" valueXPath="artist/@source" />
        <field name="artist" type="text" valueXPath="artist/value" />
        <field name="title" type="text" valueXPath="title" />
    </fields>
</DataSource>

I was under the impression that the JAXB generated classes would cause an error as they were not just simple DTO's, but they seem to work ok - annotations and all.

I'm still lost as to how I would write an xpath that would get at the text contents of a complex node though using the SmartGWT classes. I've looked at loads of XPath resources now and asked around the office, but it's still no clearer, there seem to be several ways to do it, none of them that work in my example, e.g. artist/text() artist/. (Am I missing something obvious here???)

The JSTranslater seems to be a very strict representation of the 'standard', i.e. when creating the JSON object from the Document object it drops the text content of a node if it is a complex node and only converts the attributes. Is there a way of getting it to keep the text content and convert it too?

Other JSON translators I've looked at will include the text content of a complex node in a JSON field. (Although different translators work in different ways) e.g. If you run the XML string through the org.json.XML.toJSONObject() method, it puts the tag text contents in a JSON field called "contents" (which it defines itself) along with the other named attributes.
e.g. artist:{id:"224",source:"devAdmin",contents:"Artist Name"}
(I appreciate I'm comparing a String parser with an object parser here...)

I'm also curious as to why, if you can specify an XML data file as the source for a DataSource using "dataURL", why can't you do it with an XML String? Or is it that you just can't use complex types in your XML file if you want to access the tag text value?

Overall, the JAXB approach seems to work. There are some concerns that it will be slower than a more direct DataSource/XML integration as we have to unmarshal the String to an object, then marshal back to a String each time, but at this stage, I just want something that works...!

:)

**Isomorphic** · 25 Nov 2010, 11:11

Confused - since you are now working with beans directly why are you still looking at APIs for processing XML - just curiosity?

JXPath docs suggests that someElement/text() is the correct selector, however, Googling does reveal some people saying it works and some saying it doesn't work.

As far as preserving the text content when translating to JSON, that's something we do in other contexts (eg client-side WSDL integration) but on the server, you're 1) probably using the wrong approach if you're interacting with XML directly 2) have probably made a mistake if you end up with a complete element in your output data. So, it's not the default, and from what we understand now that you're interacting with beans you shouldn't need this anymore, but you can add a DMI that looks at the dsResponse.getRecords() and grabs the value of the field from each Map, which will be an Element, and replaces that value with the text content.

**firebet** · 26 Nov 2010, 02:40

It's more curiosity now although I'm still looking because we may run into problems in the future. There is a requirement to process much larger and more complex XML records down the line, so I want to make sure the solution I deliver is scalable and performant.

I figured I can't be the only person facing a problem like this (i.e. I have XML records that I want to update using a SmartGWT UI) and I wanted to understand the cleanest and simplest approach. If JAXB/DTOs is recommended, then fine, I just thought there might be a more direct integration approach. You use XML files in your client DataSource examples, so I figured there would be an easy way to map XML elements and attributes directly from an XML Document to named fields on the UI in the DataSource config (without manually converting the XML to custom DTOs first). Probably a case of not reading the documentation carefully enough upfront...? ;)

As for the JSON conversion, what wasn't clear to me was why JSTranslater.toJS(org.w3c.dom.Document) would drop the text content from complex tags and not attempt to create a JSON field like "content" with the text. From other docs I've read, the standard for converting elements to JSON seems to be arbitrary, some converters drop the text because in complex Elements there is effectively no 'named field' to map it to, while others create a special field like "content" and put the text in it.
e.g. By default, JSTranslater seems to convert the Element <title>Hello</title> to title:"Hello" but <title id="101">Hello</title> converts to title:{id:"101"}

You alluded to the fact that if I got the right xpath notation in the DataSource config, that I could get the text from the Element and add it to a named field that I specify in my DataSource config. Unfortunately, I'm still none the wiser as to what the correct xpath notation would be, as you've said, after Googling and asking around the generally accepted "someElement/text()" doesn't work and without spending some time debugging what happens in JSTranslater and the DataSource, I doubt I'll find the answer. I'll look at dsResponse.getRecords() anyway.

Overall though, I really appreciate the pointers, I'm making progress now.
Many thanks.

**Isomorphic** · 26 Nov 2010, 11:14

Still confused. If you're working directly with beans then you should not need either server-side XML processing or DTOs (did you read the section in the QuickStart on this?).

You're asking for the cleanest approach - when you have a Java Object model and you instead work with XML documents that are a serialization of that Java Object model, that's kind of like choosing to work with a CSV dump of a SQL database instead of the database itself. Working with the actual object model is the clean approach.

As we covered, in other contexts when we convert to JSON we preserve the text content (under the name "xmlTextContent", but the field can be renamed). We don't do it in this case because it's a sign of a bad approach that you would end up in this situation at all.

If you were forced down this path, and you wanted to get the text content, you would set an XPath that would cause the element itself to be retrieved (which may in this case be no XPath, or just "artist", but you've never shared the XML document itself), then apply the post-processing to the DSResponse that we described.

But this is neither the recommended nor the cleanest path. Please confirm that you've switched over to working with beans and understand how to avoid the need to use DTOs - we can't keep explaining nuances of an integration approach that we do not recommend.

**firebet** · 27 Nov 2010, 03:25

An example of the XML was included in my first post - I created a static String in the DataSource class to represent it:

Code:

<product id='101'><artist id='224' source='devAdmin'>Artist Name</artist><title>Some Title</title></product>

Sorry, maybe I haven't been clear enough? I understand the best approach would be to have a relational db with a neatly mapped bean-model but that is not what I have to work with. The data I need to manage is stored and retrieved as an XML document, so, when I retrieve the document for updating in the UI, I'm forced to try and generate an object model from it (using the schema and JAXB) to allow me to use SmartGWT the way that has been recommended.

I've abandoned any plans to try and process the XML directly as a 'Document' using JSTranslater and I am using the JAXB-generated classes (beans) to try and implement a solution. I merely wanted to understand what the JSTranslater class did with the text data when it converted complex Elements to JSON, because in my original approach, when I debugged the resulting JSON object in Firebug, I didn't see the tag text, only the attributes.

Thanks.

**Isomorphic** · 27 Nov 2010, 13:00

What we thought you were doing is using an XML representation derived from a clean beans object model. Sounds like it's the other way around - you are deriving JAXB beans from an XML message, and you have no more direct way to access the data than the XML message?

Regardless, either direct XML usage or JAXB usage in this case is fine. With XML you have the mystery of the apparent JXPath bug with receiving text, but we gave you a workaround for that. With JAXB, so far as we know, you have no issues so far. Given the constraint of working with XML messages from some remote server (as we understand it) the two approaches are about equivalently "clean".

Announcement

XML translation in DataSource

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment