To any Editors Gurus: I could use some ListEditor use help for the GWT demo I've made...

896 views
Skip to first unread message

Brandon Donnelson

unread,
Feb 2, 2012, 7:04:21 PM2/2/12
to google-we...@googlegroups.com
I'm trying to use a list editor as a sub editor and the when the flush happens the list comes back null. The input boxes for the list seem to render fine. I'm not sure the backing of the PeopleDataProxy gets established with the current configuration. 

I'm still digesting the interfaces and there use compared with the results they do. The I haven't grasped all the nuances of the Editors automation yet. 

The question is, how can I get the listEditor to work?

The Person Editor, which has a list of Todos, or child editor

Todos list editor - will render, but won't give back a list (need backing established from PeopleDataProxy?)

Todos Item 

DTOs



Brandon Donnelson

unread,
Feb 2, 2012, 7:05:40 PM2/2/12
to google-we...@googlegroups.com
I forgot the location of the demo:




Brandon Donnelson

unread,
Feb 2, 2012, 7:06:07 PM2/2/12
to google-we...@googlegroups.com
I haven't added the listeditor to the working demo...

Patrick Julien

unread,
Feb 3, 2012, 9:06:29 AM2/3/12
to google-we...@googlegroups.com
Start by checking your paths.


PeopleDataProxy has a field called "todos" but PersonEditor has @UiField called todosEditor with no custom path



Thomas Broyer

unread,
Feb 3, 2012, 10:17:47 AM2/3/12
to google-we...@googlegroups.com


On Friday, February 3, 2012 3:06:29 PM UTC+1, Patrick Julien wrote:
Start by checking your paths.


PeopleDataProxy has a field called "todos" but PersonEditor has @UiField called todosEditor with no custom path

Yes, but that's how it's supposed to be: in the absence of @Path annotation, any "Editor" suffix is automatically removed before using the field name as the path.

I haven't see anything wrong in the files (except your –Brandon's– EditorSource should override dispose and setIndex to respectively remove and reorder your subeditors from/within the FlowPanel container, and to be future-proof, you should check the index passed to methods to be positive: see http://code.google.com/p/google-web-toolkit/issues/detail?id=6959 )

Brandon Donnelson

unread,
Feb 3, 2012, 11:58:16 AM2/3/12
to google-we...@googlegroups.com
Thanks for the comments and looking at my code! :)

I may be getting close to the solution. I have forgotten .with("todos") in the request factory request so they aren't being loaded in the initial request. Not sure if this triggers the correct backing. But all the chaining and list editor stuff seems to have been instantiated correctly from what I can tell. Although the listwrapper never gets used b/c the value is null. 


ListEditor.setValue(list<TodoDataProxy> value) {
   //... I think sets up the backing here in list editor
} 
I've found that this is always null in all the configurations I've tried.


String s = EditorHierarchyPrinter.toString(driver);
System.out.println("EditorHierarchyPrinter = " + s);

EditorHierarchyPrinter = 
com.gonevertical.client.app.requestfactory.dto.PeopleDataProxy
com.gonevertical.client.views.peopleedit.editor.PersonEditor
ValueAwareEditor 
nameFirst
java.lang.String
com.google.gwt.editor.ui.client.adapters.ValueBoxEditor
ValueAwareEditor 
nameFirst
java.lang.String
com.google.gwt.editor.ui.client.ValueBoxEditorDecorator
ValueAwareEditor 
nameLast
java.lang.String
com.google.gwt.editor.ui.client.adapters.ValueBoxEditor
ValueAwareEditor 
nameLast
java.lang.String
com.google.gwt.editor.ui.client.ValueBoxEditorDecorator
ValueAwareEditor 
active
java.lang.Boolean
com.google.gwt.editor.client.adapters.TakesValueEditor
ValueAwareEditor 
gender
java.lang.Integer
com.google.gwt.editor.client.adapters.TakesValueEditor
ValueAwareEditor 
note
java.lang.String
com.gonevertical.client.views.widgets.richtextarea.RichTextAreaEditor
ValueAwareEditor 
todos
java.util.List
com.google.gwt.editor.client.adapters.ListEditor
ValueAwareEditor

Brandon Donnelson

unread,
Feb 3, 2012, 1:14:52 PM2/3/12
to google-we...@googlegroups.com
Thomas thanks for putting so much work into the GWT codebase! :) Amazing!

Can I ask if the having the ListEditor as a sub editor if driver should call the context.edit  or context.create (for TodoDataProxy in list) for list creation or editing?

I'm puzzled that on save the flush, the ListEditor.flush() { list.flush() } is null and throws the exception. Then I find that ListEditor.setValue(T value) needs to take place. 

I'm wondering if i need to tell the driver more here about the list, that is edit or create? On list null I'm wondering if I should create array list to get things going. But I'm thinking the editor should take care of this, but maybe not?

Thanks for the help. 

Patrick Julien

unread,
Feb 3, 2012, 1:35:09 PM2/3/12
to google-we...@googlegroups.com


On Friday, February 3, 2012 11:58:16 AM UTC-5, Brandon Donnelson wrote:
Thanks for the comments and looking at my code! :)

I may be getting close to the solution. I have forgotten .with("todos") in the request factory request so they aren't being loaded in the initial request. Not sure if this triggers the correct backing. But all the chaining and list editor stuff seems to have been instantiated correctly from what I can tell. Although the listwrapper never gets used b/c the value is null. 


You don't need .with("todos"), you need to RequestFactoryEditorDriver#getPaths.  Your driver knows all the paths you need to put in your request.



Brandon Donnelson

unread,
Feb 3, 2012, 4:14:02 PM2/3/12
to google-we...@googlegroups.com
Thanks Patrick for checking into this. I really appreciate the help. :)

I added getPaths to the context. Although I'm still puzzled by why the ListEditor list is null on flush. 


I also added dispose and setIndex to the listeditor... So when the listeditor adds a inputbox and then disposes it on instantiation. This also creates a challenge to add another input box b/c I would then need to have reference to the context in the subeditor so I could create an instance of the dtoproxy. Where if I use ListEditor.createEditorforTransversal() creates a new editor source but then it removes it on the same hand.

My goal is to figure out why the ListWrapper in ListEditor.setValue(T value) doesn't get instantiated and why list.flush throws on a driver flush. 

Brandon Donnelson

unread,
Feb 3, 2012, 5:24:45 PM2/3/12
to google-we...@googlegroups.com
Wahoo!! I just solved the issue. This got the ListEditor.setValue(T value) to work correctly and then rendered the items. Awesome! I'll disclose the results later.

I had forgotten to annote the owned collection in PeopleData:

Brandon Donnelson

unread,
Feb 3, 2012, 11:39:30 PM2/3/12
to google-we...@googlegroups.com
I committed the working code that will load the ListEditor items and flush list will not fail. Works quite nice. I added some data on the server side to figure that out. 

I'm wondering what the best method to add an item to the list is. Typically I would need a reference to the context, but it seems like the editor should have a method.


Brandon Donnelson

unread,
Feb 4, 2012, 12:41:42 AM2/4/12
to google-we...@googlegroups.com
I sent the context into the list editor. AddItem or adding an item (element) works good now. Would be nice if it took care of adding an element on its own. Seems it carries request factory context in the editors chain. 


The working demo > https://demogwtpeople.appspot.com 

Thanks for the help!

Thomas Broyer

unread,
Feb 5, 2012, 11:07:35 AM2/5/12
to google-we...@googlegroups.com
FYI, we have a very similar code in our project, with on major difference: we use HasRequestContext to have the RequestContext passed down to editors, instead of calling your setContext method "by hand".
See http://code.google.com/p/google-web-toolkit/issues/detail?id=5892 for the rationale: it was the exact same use case.

Brandon Donnelson

unread,
Feb 5, 2012, 2:27:13 PM2/5/12
to google-we...@googlegroups.com
That is slick! Thanks for sharing that! That helps simplify the context push into the subeditors. 


Took me a minute to figure out what <T> was supposed to be. At first I thought it should be HasRequestContext <TodoDataProxy> or HasRequestContext<PeopleDataProxy>. Then I realized what was going on. So for those who find this in the future, may note that HasRequestContext<List<TodoDataProxy>> has List in it.

I have to say the editors have been challenging but very rewarding find!

Brandon Donnelson

unread,
Feb 5, 2012, 2:40:55 PM2/5/12
to google-we...@googlegroups.com
In this project I've used an Owned Collection for TodoDataProxy in App Engine. When a Todo list item is removed and then a persist request, the shortened list is sent to App Engine. In this case I am using an owned collection, so I need to remove the child independently. And this is probably due to JDO backing not having automatic orphan deletion, but I thought'd I'd ask and it makes sense what I said and possibly if removing a child had an automatic method in the bean. 

I'm going to assume the owned collection item deletion from the database is my duty and not the auto bean's duty.

I'm going to check for orphans and remove them on the server side for now unless something else pops out at me. I also wanted to add a few more of the key words to this thread for helping others in the future. :)

Thanks for the help!

Brandon Donnelson

unread,
Feb 6, 2012, 10:32:09 AM2/6/12
to google-we...@googlegroups.com
I finished a working ListEditor using an Owned Collection on AppEngine. I also switched to JPA backing. 

Something to note. Removing an item form an owned collection has to be done independently of a persist. I tried to do it on there server side but I get a transient error. And you can't use the object itself because its already been touched by a context and in edit mode.  


Alex opn

unread,
Feb 6, 2012, 4:31:59 PM2/6/12
to google-we...@googlegroups.com
Thanks for sharing all this : )

Examples for Editors are hard to find and yours is great!

Brandon Donnelson

unread,
Feb 6, 2012, 5:27:06 PM2/6/12
to google-we...@googlegroups.com
Thanks :)

Brandon Donnelson

unread,
Feb 6, 2012, 5:29:02 PM2/6/12
to google-we...@googlegroups.com
I'm going to tag this into the thread again, just in case :)

http://c.gwt-examples.com/home/ui/places - demo and source links for the editors demo..

Brandon

Benjamin Seber

unread,
Feb 11, 2012, 10:00:00 AM2/11/12
to google-we...@googlegroups.com
Thanks for all your stuff Brandon!

I also got stuck with the Editor Framework over the last days...
And I still have one problem...

ListEditor#getList#remove does not really work if you use constraint annotations.
AbstractRequestContext#create puts the entity in a map. But it will never be removed from it, not until AbstractRequestContext#processPlayload is finished successfully. So AbstractRequestContext#makePayload uses all created proxies which will be validated.

Am I wrong? Should it work or does anyone have a solution?

Thomas Broyer

unread,
Feb 11, 2012, 10:32:18 AM2/11/12
to google-we...@googlegroups.com
Your problem has nothing to do with editors actually, only with RequestFactory. It's true that any edited proxy will be part of the request, whether it's passed (or referenced by another proxy, transitively, that is passed) as argument to a service method or not; and it's also true that as soon as you edit() a proxy, all the proxies it references are automatically edit()ed as well.

Given that there's an explicit unit-test testing that such a proxy is actually sent to the server, I guess it's by-design. I suppose one use-case was to edit proxies, make changes to them, and send them for validation without even calling a service method. I fail to see the real usage though, as the objects would be frozen after the call.

I however agree I'd rather only "referenced" proxies are sent to the server, and if you want to validate your proxies then create a dummy no-op service method (again, I'd fail to see the real usage, but the point is to say it'd be easy to have the same behavior with only small changes).

Another use-case could be to send proxies (without changes) to the server so that you can have EntityProxyChange events back, and thus detect deleted or updated objects; but then again I fail to see a real use-case, as detecting updated objects without retrieving them at the same time is kind of useless in 90% of cases, and again, you can easily have that behavior by only adding a service method call (if you want the changes back, then make an "echo" method that returns its argument, it'd be enough).

Feel free to file an issue and link to this message, and let's see how its getting triaged.

Craig Day

unread,
Mar 5, 2012, 11:35:51 PM3/5/12
to google-we...@googlegroups.com

Yeah, things break down pretty badly due to this behaviour. Child proxies added and then removed via ListEditor are still sent to the server on fire(), and subsequent validation of these empty proxies fails the entire request. Really only referenced proxies should be sent, or perhaps a detach/uncreate/delete method on RequestContext that undoes the create() call.

Has there been an issue created for this?

Has anyone come up with a workaround for the problem?

Cheers
Craig

Craig Day

unread,
Mar 6, 2012, 12:08:48 AM3/6/12
to google-we...@googlegroups.com

OK. Not exactly my finest hour but I have worked around this by creating my own version of AbstractRequestContext.java that has one additional method:

    public void detach(EntityProxy proxy) {
        AutoBean autoBean = state.editedProxies.remove(proxy.stableId());
        autoBean.setTag(REQUEST_CONTEXT_STATE, null);
    }

and at the point where I remove a previously create()ed proxy that I dont want sent to the server:

    ((AbstractRequestContext) requestContext).detach(listEditor.getList().remove(index));

Cheers
Craig

Thomas Broyer

unread,
Mar 6, 2012, 6:51:18 AM3/6/12
to google-we...@googlegroups.com


On Tuesday, March 6, 2012 5:35:51 AM UTC+1, Craig Day wrote:

Yeah, things break down pretty badly due to this behaviour. Child proxies added and then removed via ListEditor are still sent to the server on fire(), and subsequent validation of these empty proxies fails the entire request. Really only referenced proxies should be sent, or perhaps a detach/uncreate/delete method on RequestContext that undoes the create() call.

Has there been an issue created for this?

 
Has anyone come up with a workaround for the problem?

See issue ;-) 

Craig Day

unread,
Mar 7, 2012, 12:17:08 AM3/7/12
to google-we...@googlegroups.com
Thanks Thomas. Your workaround is slightly more palatable :)

Cheers
Craig

Brandon Donnelson

unread,
Mar 10, 2012, 5:38:40 PM3/10/12
to google-we...@googlegroups.com

I've been using this to remove items from an owned collection or list. Removing them from the datastore first. 

Human izatara

unread,
May 8, 2012, 10:52:21 AM5/8/12
to google-we...@googlegroups.com
Hi guys!
does anyone have suggestion for my problem? :

On Friday, February 3, 2012 3:34:21 AM UTC+3:30, Brandon Donnelson wrote:
I'm trying to use a list editor as a sub editor and the when the flush happens the list comes back null. The input boxes for the list seem to render fine. I'm not sure the backing of the PeopleDataProxy gets established with the current configuration. 

I'm still digesting the interfaces and there use compared with the results they do. The I haven't grasped all the nuances of the Editors automation yet. 

The question is, how can I get the listEditor to work?

The Person Editor, which has a list of Todos, or child editor

Todos list editor - will render, but won't give back a list (need backing established from PeopleDataProxy?)

Todos Item 

DTOs



Reply all
Reply to author
Forward
0 new messages