Can't Drop Tree Node on TreeGrid Null Root

[chimpeenuts]

Using Smart GWT 3.0 nightlies. Power Edition.

I have a TreeGrid where I'm allowing the user to re-order and re-parent nodes.

Unfortunately, there's no way to move a child 'leaf' or sub-folder up to the root level.

Here are the properties I set on the TreeGrid:

_tree.setCanReorderRecords(true);
_tree.setCanAcceptDroppedRecords(true);
_tree.setCanReparentNodes(true);

Since my Tree does not have a ROOT node, there's no ROOT node to drag children UP to. The UI does show an indicator that I'm dragging up to the root level, but when I let go, the UI doesn't update.

I noticed that the response being sent to the server *DOES NOT* include an update to the parentId. This appears to be the 'BUG'. When dragging nodes to other parents, the new parentId field exists in the 'values' element but I think the Smart GWT client code is not including or stripping away the parentId because it's value is NULL. But I want the parentId to be set to NULL on the backend so that the TreeGrid will show the node at the 'root' level.

Here's the update request when trying to move a child node to the root level. NOTE the omission of parentId in the values element:

 <transaction xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
    xsi:type="xsd:Object">
    <transactionNum xsi:type="xsd:long">22</transactionNum>
    <operations xsi:type="xsd:List">
      <elem xsi:type="xsd:Object">
        <criteria xsi:type="xsd:Object">
          <id xsi:type="xsd:long">37</id>
        </criteria>
        <values xsi:type="xsd:Object">
          <id xsi:type="xsd:long">37</id>
          <open xsi:type="xsd:boolean">true</open>
          <title>b</title>
          <category xsi:type="xsd:boolean">true</category>
          <userId xsi:type="xsd:long">1</userId>
          <locked xsi:type="xsd:boolean">false</locked>
          <hostName>37</hostName>
          <children xsi:type="xsd:List">
            <elem xsi:type="xsd:Object">
              <id xsi:type="xsd:long">16</id>
              <parentId xsi:type="xsd:long">37</parentId>
              <open xsi:type="xsd:boolean">false</open>
              <title>packers_RR_7206_01</title>
              <category xsi:type="xsd:boolean">false</category>
              <userId xsi:type="xsd:long">1</userId>
              <hostName>packers_RR_7206_01</hostName>
              <device_id xsi:type="xsd:long">20</device_id>
              <locked xsi:type="xsd:boolean">true</locked>
            </elem>
          </children>
        </values>
        <operationConfig xsi:type="xsd:Object">
          <dataSource>categoryDevice</dataSource>
          <operationType>update</operationType>
        </operationConfig>
        <appID>builtinApplication</appID>
        <operation>categoryDevice_update</operation>
        <oldValues xsi:type="xsd:Object">
          <id xsi:type="xsd:long">37</id>
          <parentId xsi:type="xsd:long">38</parentId>
          <open xsi:type="xsd:boolean">true</open>
          <title>b</title>
          <category xsi:type="xsd:boolean">true</category>
          <userId xsi:type="xsd:long">1</userId>
          <locked xsi:type="xsd:boolean">false</locked>
          <hostName>37</hostName>
          <children xsi:type="xsd:List">
            <elem xsi:type="xsd:Object">
              <id xsi:type="xsd:long">16</id>
              <parentId xsi:type="xsd:long">37</parentId>
              <open xsi:type="xsd:boolean">false</open>
              <title>packers_RR_7206_01</title>
              <category xsi:type="xsd:boolean">false</category>
              <userId xsi:type="xsd:long">1</userId>
              <hostName>packers_RR_7206_01</hostName>
              <device_id xsi:type="xsd:long">20</device_id>
              <locked xsi:type="xsd:boolean">true</locked>
            </elem>
          </children>
        </oldValues>
      </elem>
    </operations>
  </transaction>

Here's a transaction showing moving a child to another parent, BUT not root. NOTE the parentId IS included here with an actual value.

transaction xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
    xsi:type="xsd:Object">
    <transactionNum xsi:type="xsd:long">23</transactionNum>
    <operations xsi:type="xsd:List">
      <elem xsi:type="xsd:Object">
        <criteria xsi:type="xsd:Object">
          <id xsi:type="xsd:long">37</id>
        </criteria>
        <values xsi:type="xsd:Object">
          <id xsi:type="xsd:long">37</id>
          <parentId xsi:type="xsd:long">2</parentId>
          <open xsi:type="xsd:boolean">true</open>
          <title>b</title>
          <category xsi:type="xsd:boolean">true</category>
          <userId xsi:type="xsd:long">1</userId>
          <locked xsi:type="xsd:boolean">false</locked>
          <hostName>37</hostName>
          <children xsi:type="xsd:List">
            <elem xsi:type="xsd:Object">
              <id xsi:type="xsd:long">16</id>
              <parentId xsi:type="xsd:long">37</parentId>
              <open xsi:type="xsd:boolean">false</open>
              <title>packers_RR_7206_01</title>
              <category xsi:type="xsd:boolean">false</category>
              <userId xsi:type="xsd:long">1</userId>
              <hostName>packers_RR_7206_01</hostName>
              <device_id xsi:type="xsd:long">20</device_id>
              <locked xsi:type="xsd:boolean">true</locked>
            </elem>
          </children>
        </values>
        <operationConfig xsi:type="xsd:Object">
          <dataSource>categoryDevice</dataSource>
          <operationType>update</operationType>
        </operationConfig>
        <appID>builtinApplication</appID>
        <operation>categoryDevice_update</operation>
        <oldValues xsi:type="xsd:Object">
          <id xsi:type="xsd:long">37</id>
          <parentId xsi:type="xsd:long">38</parentId>
          <open xsi:type="xsd:boolean">true</open>
          <title>b</title>
          <category xsi:type="xsd:boolean">true</category>
          <userId xsi:type="xsd:long">1</userId>
          <locked xsi:type="xsd:boolean">false</locked>
          <hostName>37</hostName>
          <children xsi:type="xsd:List">
            <elem xsi:type="xsd:Object">
              <id xsi:type="xsd:long">16</id>
              <parentId xsi:type="xsd:long">37</parentId>
              <open xsi:type="xsd:boolean">false</open>
              <title>packers_RR_7206_01</title>
              <category xsi:type="xsd:boolean">false</category>
              <userId xsi:type="xsd:long">1</userId>
              <hostName>packers_RR_7206_01</hostName>
              <device_id xsi:type="xsd:long">20</device_id>
              <locked xsi:type="xsd:boolean">true</locked>
            </elem>
          </children>
        </oldValues>
      </elem>
    </operations>
  </transaction>

[Isomorphic]

Root is implied by the absence of a parentId. You can also set an explicit ID for root via DataSourceField.rootValue.

[chimpeenuts]

Isomorphic -

First, thanks for the reply.

Second, I understand that the absence of parentId implies root, but the Smart GWT code is not handling this situation correctly. Right now, Smart GWT is not correctly passing a NULL parentId to the backend so the Smart GWT Server is not updating the database with parentId = NULL. If Smart GWT client does not pass parentId in the 'values' collection of the DSRequest, then the value in the database remains the same and it's impossible to move a node (either leaf or folder) up to the root level.

Third, I am going to give DataSourceField.rootValue a shot, but I still think there's a 'bug' in the Smart GWT client side datasource/request code that omits the parentId when the value is NULL when it shouldn't. I'm assuming this is done to improve performance since passing an empty element in the 'values' collection adds bytes to transfer but without it, you can't re-parent a node to the root in a TreeGrid with no root node.

[Isomorphic]

From a brief look we should be sending an explicit null in this case. This might be a problem specific to RestDataSource or to just the XML format of RestDataSource. We've queued it up to be looked at, but it's behind lots of other bugs since the best practice is to use a non-null rootValue.

[chimpeenuts]

Isomorphic -

I can confirm that, at least on the GWT 3.0 nightly I have, NULL is *not being sent* from the client to the server (see my XML payloads above extracted from Firebug during two drag and drop tests -- first one is dragging to root/null, second one is dragging to an actual tree folder).

I'm not sure if your internals use the RestDataSource or XML, but I'm using SQL-based datasources and am not handling anything on the server side (I'm using the default Smart GWT Server handling).

So I do think that passing <parentId>NULL</parentId> is a necessary fix but I also understand bug lists and backlogs =P.

I'll try the rootValue but have my reservations that will solve things...I have a feeling I'm going to have to write custom drop handling logic to make things work right.

[Isomorphic]

Since you've raised this:

I'll try the rootValue but have my reservations that will solve things...I have a feeling I'm going to have to write custom drop handling logic to make things work right.

Please update this thread once you've discovered that custom drop handling is in fact not required :)

[chimpeenuts]

So in my code I set the tree root value property:

_tree.setTreeRootValue(-1);

I then make sure that my backend processing inserts -1 into the database table for 'parentId' field for those nodes I want at the 'root' level.

Now, I can successfully drag nodes to and from the tree root now without needing to write any custom code.

Thanks for the fix Isomorphic!

[Isomorphic]

The latest 3.1d builds now also include support for RestDataSource sending an explicit "nil" element (with attribute xsi:nil="true") for Records that include explicit null values, including a null rootValue (see DataSourceField.nillable). This will not be backported - use a rootValue such as -1 or the String "NULL" in earlier versions.