Announcement

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

    #16
    I removed the calls to setCacheData and setCacheAllData and the problems still exist.

    Comment


      #17
      We've tried the test case and we do indeed see the disappearing row issue.

      Removing the "setCacheAllData(true)" call fixes the issue for us.

      This makes sense - cacheAllData is intended for the case where a dataSource is not truly clientOnly -- it performs an initial fetch against the server and picks up a complete data set which it then caches locally and uses to furnish data for subsequent fetches.
      However unlike a normal clientOnly dataSource a dataSource with cacheAllData set does hit the server to perform update, add and remove operations.

      So - can we verify - if you take the posted test case and modify it only by removing the call to 'setCacheAllData(true)' and run, do you still see the issue? We'd very much expect this to resolve this issue for you (and it does for us!)

      Comment


        #18
        Excellent -- removing that one line does indeed fix the problem. Thank you very much.

        I'm racing ahead with some other related issues now, and have a few questions:

        1. Within this simple program, how would I tap into the client-server communication you are referring to as the various events take place? For example, where would I begin to catch the various REST and/or DSRequest/DSResponse events that are occurring? Please understand that in my production program, I already have a server mechanism that is working well for me -- I'm incorporating the use of SmartGWT into that program, and was hoping to do so mostly on the client side of things, at least to start. I'd rather not completely re-write all of that code (which includes a customized/proprietary persistence mechanism on the server side) just to be able to sling XML or JSON back and forth with SmartGWT.

        2. Is attaching an "EditorExitHandler" to my editable field a "best practice"? If so, within that implementation, I've noticed that asking the passed EditorExitEvent for its Record returns the unmodified object. What's the correct idiom for getting the new version?

        3. In that same handler, if I ask the EditorEditEvent for the "newValue", I get an Object whose type always seems to be String (even though I've set the field type to be Integer). I've noticed that Integer.toInteger(String) is not available to me at the client side of the code (ie, can't be compiled to JavaScript), so what is the basic idiom for type conversions?

        4. Possible bug: This call
        Code:
                     EditCompletionEvent ecc = editorExitEvent.getEditCompletionEvent();
        generates a ClassCastException in your code.


        Thanks.

        Comment


          #19
          1. You really really need to read the QuickStart Guide, especially the Data Integration and Server Framework chapters. The best approach for existing server-side persistence is DMI (as the QuickStart Guide tells you). You will not have to deal with JSON or XML at all with this approach (also covered in the guide).

          2,3. No, not unless you want to do something on exit *beyond* save (which is automatically handled). See the ListGrid Editing overview about getting the edited vs non-edited values.

          4. There was a bug like this, already corrected weeks ago - make sure you're using the fully patched version from smartclient.com/builds.

          Comment

          Working...
          X