Announcement

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

    TreeGrid Drag&Drop fetchData({}) and fetchData({criterias})

    Hi Communit/Isomorphic

    I am using: SmartClient Version: v9.0p_2013-08-28/LGPL Deployment (built 2013-08-28)
    I can provide more informations if needed.

    I am using 2 ListGrids both are using the same DataSource.
    Other than that, they are seperate. Don't need to move between the ListGrids.

    With ListGrid_1 am am doing fetchData({}, "Mycallback")

    If I do a Drag&Drop moving a node to a different folder everything is fine.
    The node gets removed from the original parent and will be placed to the new folder.
    The overloaded FolderDrop() is called ... doing some logging, and calling this.Super("folderDrop"), arguments)
    The Super FolderDrop than calls an updateData(), the DataSource is bound to a server, not local.
    Server sided, Data is updated correctly.

    Now about my second ListGrid.
    The only difference is that I do fetchData({criteria,criteria,criteria...}, callback, {})
    As soon as Super folderDrop calls udpateData, the Data is updated on the server, like in the first ListGrid.
    But the moved object/node vanishes.

    I found this one.
    http://forums.smartclient.com/forum/...op-on-treegrid

    If I do the same, the TreeGrid will be correctly visually updated on client side. But as soon as I try to combine it with server communication like calling this.Super("folderDrop", arguments) the node vanishes again. Still serversided, data was updated correctly.

    So I don't think its a server sided issue.

    Also I don't think this is the right way, because with the first TreeGrid there is also no need to do stuff like data.addList.

    There are no stacktraces, or errors in the log.
    If someone could point me to the right direction, it would be very helpfull. I am reading documentations and forum threads, but couldn't find the right solution yet.

    My guessing is, it's something simple.

    Thanks a lot

    #2
    If the record you return from the server in the response for the "update" operation doesn't match the criteria you applied to the TreeGrid, the record will (correctly) disappear from the tree.

    So check the data you are returning - most likely it is partial or it's PK value is missing or has changed, something like that.

    The "ResultTree" log category can be turned on to get more logs of what's going on.

    Comment


      #3
      Hi Isomorphic,

      that solved my issue. Thanks a lot!

      ResultTree log category in Smartclient Debug Console showed:
      didn't match filter ( .. ) 1 row removed, 0 updated.

      My Initial Fetch is using Criterias. toggleFolder/fetch Function is fetching without these criterias.
      Later "update" operations follow the toggleFolder criterias. But the ResultSet seems to only accept the criterias from the initial fetch.

      So its like the initial fetch only fetches the main objects. Informations for the child objects are fetched on Demand.

      My current solution is to use setCriteria after my initial fetch.
      These criteria settings are then respected with toggleFolder/dropFolder functions.

      This leads to invalidatingCaches, and bsc of that its refetching all data again
      Guessing with a propper solution, i would only have 1 initial fetch for all data. So I will need to continue training/investigating.

      I think its very important to clearly understand how Databinding works in smartclient. There are enough articles about these topics.


      But now the objects does not vanish anymore. And DS Operations are ok.

      So its still not the best solution. But now I can keep the wheel turning.

      Best regards
      TSdev

      Comment


        #4
        Criteria set up initially in a fetchData() call would be expected to be used in subsequent fetches initiated by toggleFolder. If you aren't seeing that, first update to a recent version that has all patches and to at least 10.1, and if you still have the problem, please put together a minimal test case demonstrating it.

        Note that we're not sure why this problem is being blamed for records disappearing. The records were disappearing based on your initial criteria, so having criteria added to the other operations wouldn't cause the records to stick around - they still have to match the initial criteria.

        Comment

        Working...
        X