Announcement

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

    JavaScriptException on DynamicForm saveData with java Object type record attributes

    Hi Isomorphic,
    First, thanks a lot for a great product.
    We are running Smart Gwt 3.0 patch of february 14th / SC_SNAPSHOT-2012-02-14_v8.2p/Pro Deployment (built 2012-02-14).
    The error was introduced in Smart Gwt 3.0 release build.

    We have some clientOnly DataSources.
    If a form is used to edit a record containing a java Object type attribute (record.setAttribute(String attrName, Object attrVal) has been set on the record), the form.saveData() fails with a JavaScriptException.
    Also any attempt to update an existing DataSource record to add an Object type attributes fails in the same manner.

    In hosted mode the exception looks like this in GWT Developer console on any browser:
    Code:
    Caused by: com.google.gwt.core.client.JavaScriptException: (null): null 	at
     com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserChannelServer.java:237) 	at
     com.google.gwt.dev.shell.ModuleSpaceOOPHM.doInvoke(ModuleSpaceOOPHM.java:132) 	at
     com.google.gwt.dev.shell.ModuleSpace.invokeNative(ModuleSpace.java:561) 	at
     com.google.gwt.dev.shell.ModuleSpace.invokeNativeVoid(ModuleSpace.java:289) 	at 
    com.google.gwt.dev.shell.JavaScriptHost.invokeNativeVoid(JavaScriptHost.java:107) 	at
     com.smartgwt.client.widgets.form.DynamicForm.saveData(DynamicForm.java) ... etc
    In compiled mode, the error is swallowed silently, but leads to trouble later on in our application. The SmartClient Developer Console does not show any messages.

    The error is easily reproducible by modifying Smart GWT Showcase->Grids->Grid-Form Binding->Add and Update samples.
    In the Add-example, modify the Save Button logic in GridFormAddSample.java to update the new record with an Object type attribute:
    Code:
            IButton button = new IButton("Save New");  
            button.addClickHandler(new ClickHandler() {  
               public void onClick(ClickEvent event) {  
                    form.saveData(new DSCallback() {  
                         public void execute(DSResponse response, Object rawData, DSRequest request) {  
                           	Record respRec = response.getData()[0];
                          	respRec.setAttribute("newAttr", new Object());
                           	dataSource.updateData(respRec);
                           	form.editNewRecord();
                            }  
                      });  
                   form.reset();  
              }
    The error happens in DataSource.updateData(respRec).

    In the Update-example, modify the getNewRecords() method in ItemData.java to add a Java Object attribute to one of the records populating the grid:
    Code:
        public static ItemRecord[] getNewRecords() {
        	ItemRecord[] itemRecords =
        		new ItemRecord[]{
                    new ItemRecord(1, "Glue Pelikan Roll-fix Permanent #950", "1088300", "A clean no-drips, no brush roll-on glue. Will not dry out. Suitable for artwork, photos or posters. Glue cartridges are 12 metres long. Refillable.", "Rollfix Glue", "Ea", 6.96, null, null),
                    new ItemRecord(2, "Glue Pelikan Roll-fix Refill Permanent #955", "1089400", null, "Rollfix Glue", "Ea", 3.73, null, null),
                    new ItemRecord(3, "Glue Pelikan Roll-fix Non Permanent #960", "1090500", null, "Rollfix Glue", "Ea", 6.96, null, null),
                    new ItemRecord(4, "Glue Pelikan Roll-fix Refill Non Permanent #965", "1091600", null, "Rollfix Glue", "Ea", 3.73, null, null)
            };
        	itemRecords[2].setAttribute("initObj", new Object());
        	return itemRecords;
        }
    The error happens on form.saveData() when editing record 3.

    We just recently acquired a Pro license for version 3.0, so our existing application is based on the LGPL SmartGwt version 2.5. Our present DataSources (~100) is type clientOnly and populated via Dtos from GWT-RPC calls. We are passing the Dtos as record attributes in our save/update procedures, so this problem is effectively a show-stopper for our migration to 3.0 Pro as of now.
    I hope you can look into it as soon as possible.
    Thanks,
    Regards Hans Petter Simonsen, EDB Ergogroup, Norway

    #2
    Hello hanspetter,

    The underlying problem is that GWT makes it tricky to detect a Java Object from JavaScript, and yet crashes mysteriously when you try to treat a Java Object like an ordinary JavaScript object. We think we have a way around this, but we have concerns that it would cause performance problems.

    The best solution is to get rid of GWT-RPC - see the FAQ for the very compelling reasons why it should not be used, regardless of whether you're on Pro or LGPL. Your current strategy needs an overhaul anyway, as it can't handle large data volume (no paging).

    A shorter-term solution is to take the DTOs out of your Record objects. There's no necessity for them to be there, and if there's a situation where you really need to look up the DTO from the Record, you could store an ID for the DTO in the Record rather than the DTO itself.

    Comment


      #3
      We've actually gone ahead and put some experimental code into 3.1d builds (not 3.0p builds) to detect and avoid touching Java objects. The two approaches below are still better approaches, and, to set expectations, we may still remove this new code or require a flag to turn it on (if it, for example, saps performance. However the code will be present in builds starting tomorrow if you want to try it out.

      Comment


        #4
        Thanks,
        I appreciate that. We will try it out.
        And although I agree that the alternative approaches are better, I would argue that while you have an api with that allows for setting and getting java objects in records, there should at least be some meaningful warnings or errors in the cases where this will not work.

        Comment


          #5
          An excellent suggestion, but one for Google, not us. We have no way of avoiding this bogus error being thrown without implementing checks that could create performance issues.

          Comment

          Working...
          X