Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    SGWT.mobile - Datasource attributes

    Hey guyz,

    I want to explain shortly some issues I ran into by diving deeper through the Datasource class of SmartGWT.Mobile.

    Still using GWT 2.4. and the mobile SDK I use maybe one week old, but for the explanations and code lines I used the current release from the 20.01.

    The Datasource class expects XML responses by default in a format, where you have record tags within data tags like:

    Code:
    <response>
      <data>
        <record>
          [<attribute>x</attribute>]
        </record>
        ...
      </data>
    </response>
    For this, Datasource.java defines in its constructor:
    Code:
    130    public DataSource() {
    131        attributes.put("dataTagName", "data");
    132        attributes.put("recordName", "record");
             [...]
    As I am not getting this structure from my backend - another record name - I wanted to change this expected structure. The mobile Datasource class does not provide a method to change its attributes externally (which is possible in SGWT, but not in mobile?), so I had to change the setAttribute() Method to public to make this possible.

    No problem so far. But using the method and changing the "recordName" attribute had zero effect. Just for testing purposes, I changed the strings in the constructor. Still, no effect. The record tag kept its name "record". That was a little suspicious behaviour so I debugged myself through the whole process.

    After some time I came across the lines where the tag name und the record name are set, which are these:
    Code:
    1342    String dataTagName = null;
    1343    if (opBinding != null) dataTagName = opBinding._getDataTagName();
    1344    String recordName = null;
    1345    if (opBinding != null) recordName = opBinding.getRecordName();
    There are a lot of funny things about those lines. First, let's point out what opBinding is. It is a HashMap of all operation Bindings. This HashMap is hold as an attribute. So it is part(value) of the attributes HashMap of a datasource under the key "operationBindings". The methods getRecordName() and getDataTagName() operate on the HashMap of operation bindings. Which also means they do not operate on the attributes Hashmap. These methods don't have a chance to access the actual attributes from the attributes HashMap. The methods in lower level, will always return null for "recordName" and "dataTagName".

    Second, though we found the problem, the question remains, why the datasource still gets the tag name "record"(or similarly "data"). That is because at different places in the code (not going in detail now), when it comes to the situation where the values are needed, those null values are catched and replaced by standard values, which are the same as the on in the constructor. That has some kind of lead to the illusion, that it uses the values from the constructor.

    I solved the problem, by changing the mentioned lines into this:
    Code:
    1342    String dataTagName = null;
    1343    if (opBinding != null) dataTagName = (String)attributes.get("dataTagName");
    1344    String recordName = null;
    1345    if (opBinding != null) recordName = (String)attributes.get("recordName");
    Getting my data now finally works. :)

    cheers,
    Markus
    Last edited by Kekzpanda; 21 Jan 2013, 03:33. Reason: The day I will have my first post without writing mistakes, you are all gonna get cookies from me...

    #2
    To sum up, the problem was that DataSource-level settings would have no effect in the presence of an operationBinding for a given operationType, whereas DataSource-level settings should have been inherited if not set on the operationBinding. This has been fixed for tomorrow's nightly build.

    Comment

    Working...
    X