Is it possible to flush the sub-editor of a CompositeEditor ?

[Eric Andresen]

I have a CompositeEditor that displays a list of sub-objects and allows me to add/delete/edit the objects in that list with sub-editors.

I am seeing a problem where I edit one of my objects inside the sub-editor, and then try to refresh the list once the edit is complete.  The issue I see is that the changes from the sub-editor are not reflected in the result of the call to chain.getValue(subEditor).   

In a previous incarnation, I had tried initializing and editing the subEditor with a new RequestFactoryEditorDriver.  When doing that I was able to call driver.flush(subEditor), and then chain.getValue(subEditor) returned the correct values.  Unfortunately doing this messed up the delegates and caused the errors/dirty flag from the sub editor to not flush up into the parent editor.  

So my question is whether it is possible to force a flush of the sub-editor in order to read its value before the CompositeEditor is flushed by the top-level driver.  

My basic flow is :

1. CompositeEditor.setValue(...)

  a.  Create sub-editors, and attach them to the chain with the sub-objects

  b.  Display the sub-objects in the list

2. Click New button

 a.   Create a new sub-editor and a new sub-object

 b.   call chain.attach(sub-editor,sub-object)

 c.   display the editor

 d.   User fills in data and clicks OK

 e.   Update list with the result of chain.getValue(sub-editor)  <-- at this point the value returned is the default values created step 2a

3.  Click Submit <-- Also at this point, the values are not flushed either.  

Step 3's problem sounds like issue http://code.google.com/p/google-web-toolkit/issues/detail?id=6081 , but I'm curious if step 2.e's problem is that as well, or if it is just not a normal case to read values out of a sub-editor before the top-level driver has flushed the whole thing?

[tom]

Don't know if it will help, but you might check out the ValueAwareEditor interface. Editors that implement it are fed with property updates during editing.

[Eric Andresen]

Thanks for the idea.  I took a quick look at that interface, but I didn't want my sub-editors to have to report every single change as they happened, I wanted the updates all at once as a single object (since my CellTable takes objects).

The route I'm currently looking down involves passing the top-level RequestFactoryEditorDriver into the editor, and then allowing my list editor to flush the entire editor tree, which as of 2.4 will flush the sub-editors.  It breaks the pattern that the editor shouldn't need to know about its driver, but so far it seems to be working.

Thanks,

Eric

[Thomas Broyer]

I don't get why you have/want to flush the subeditor of your CompositeEditor (and by the way, why aren't you using a ListEditor?)

Could you explain? (actually, I don't understand your 2.d and 2.e steps)

[Eric Andresen]

Hi Thomas,

  You are right that the ListEditor (or HasDataEditor) is the behavior I wanted to use, but my Proxies at the time were related with a Set<> interface based on the server-side requirements.  Essentially what I did was re-write the ListEditor as a SetEditor.  

  Recently we had to change our Sets to Lists anyway, so I can go back and re-visit that decision.  

A slightly better description of the problem is, consider ParentObjProxy { List<ChildObjProxy> children; }

When editing ParentObjProxy in its editor, the user should also be able to add/delete/edit the ChildObjProxys in the children relationship.

In the ParentObjProxy edit page, the children are displayed in a CellTable. 

When the user selects a row in the CellTable and clicks an edit button, a dialog is shown containing an editor for the ChildObjProxy.

The user then modifies the fields in the ChildObjProxy editor, and closes the dialog.

At this point, we would like the CellTable in the ParentObjProxyEditor to display the newly modified values.  However, the call to chain.getValue(ChildObjProxy instance's editor) that should show the values from the editor is still showing the old values, because the child editor has not been flushed yet.

What I'm trying to do is really no different than the WorkgroupEditor example at http://google-web-toolkit.googlecode.com/svn/javadoc/2.4/com/google/gwt/editor/client/CompositeEditor.html , with the only difference that I'd also like to be able to read the current values of the "Person"s from the PersonSummaryEditors and display them in a table.

I will try tomorrow converting it back to a ListEditor and see if that helps at all.  At the very least it should remove some of my boilerplate code.

Thanks,

Eric

[Thomas Broyer]

It has already been discussed before, and I believe the correct (as in "respects the Editor contract") solution is to store the changes apart, use them in your columns to display the changed value, and apply those changes to the objects on flush().

The Showcase sample does something similar (not using the Editor framework, but with a "commit changes to objects" pattern, which is exactly what's needed by the Editor framework) in the "cell sampler": http://gwt.google.com/samples/Showcase/Showcase.html#!CwCellSampler

[Jesse Hutton]

If you have flushed the changes from the editor from your dialog form to your ChildObjProxy, you should just be able to call CellTable#redraw() on the instance used by your ListEditor to have the view refreshed.

Jesse

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/C93vsH1elAUJ.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Eric Andresen]

Thanks everyone for your help.  I traced the problem with the flushing down to a portion of the Proxy's object tree not being populated with the .with() call.  When the Flusher was hitting that part of the object, the call to ctx.canSetInModel() was returning false and the flush was failing silently.  Once I fully populated the .with() for the RF call that built the new object, the flushing worked great.  

I'm working on Thomas's suggestions on how to make these editors honor their contracts, instead of making them force the flushes of the entire object tree.  At least now I'm past the technical problems.

Thanks again everyone!

---------------------------------------------------
Eric Andresen