[pjaffe]

I wouldn’t be surprised if this post maybe would have made more sense on the GWT forums, but I’m still trying to tease apart in my mind what aspect of my obstacle here might be the design pattern used by Scaffolding, or else whether this is just a core GWT concern.

My very brief question is: how can I get RequestFactoryEditorDriver working with a ListEditor that instantiates subeditors that directly edit the properties of the contained objects. The dynatablerf code sample referenced in http://code.google.com/webtoolkit/doc/latest/DevGuideUiEditors.html#Provided_Adapters only seems to manipulate the child collections, but not change values on the contained objects. And my Google searches for people dealing with this have not proven fruitful yet.

Now on to the much more verbose version of this question…

Here is how I set up my test case in ME4S (I’ve attached the project as described below). I selected defaults for everything I don’t specify below:
1. I have latest Google Plugin for Eclipse installed that has GWT 2.4
2. Created a Web Project Named “NestedEditingInGWTScaffolding” and selected Java EE 6.0
3. Edit the Google Web Toolkit settings to use GWT default version of 2.4 and set Web Application that it has a WAR file and to launch and deploy from that directory
4. Configured the Java Compiler Annotation Processing (per other forum posts) to get around the “validator issue”
5. Ran through the “Scaffolding Sprint CRUD Wizard” accepting all the defaults other than
a. Selected a Database Schema as the source
b. Used the CLASSICCARS sample Derby DB and included just the Customer and Payment tables to keep it simple
c. Opted to treat both of them as parent objects (but this will be the topic of this post)
d. My root namespace was com.nevo (but that doesn’t really matter)
e. Opted for the GWT front end (obviously this is also key to this posting)
f. Accepted all the remaining defaults
6. Configured a Web Development debug configuration for the project to not use the internal server so I can make sure to spin up Tomcat separately to avoid other issues (see https://www.genuitec.com/forums/topic/unable-to-run-a-gwt-scaffolding-app-under-development-mode/#post-321620)

Then I made a minor tweak to the generated application to try to be able to edit data about a Payment within the edit/save context of the customer. I understand this was supposedly explicitly not supported by the Scaffold application, but I’m trying to understand why it can’t be easily morphed into that.

I edited the PaymentSetEditor.java file to include a DoubleBox object named amountEditor in the inner class NameLabel and I added it to the HorizontalPanel. This was 1 line of code change as follows:
class NameLabel extends Composite implements ValueAwareEditor<PaymentProxy> {
final DoubleBox amountEditor = new DoubleBox();
…
public NameLabel(final EventBus eventBus) {
…
hp.add(checknumberEditor);
hp.add(amountEditor); // new line
initWidget(hp);

This succeeds in renders the amount in an editable form when the customer is under edit, but changes to the value don’t seem to get moved back into the corresponding proxy object as I would have expected when the RequestFactoryEditorDriver.flush() is invoked.

I’m struggling to figure out if one of the following two points explains this, whether there is some other problem, or whether I am actually heading down a dead-end which I would find hard to believe:

1. The PaymentSetEditor class declares itself with the interface “LeafValueEditor” which basically tells the GWT Editor framework to not descend into that type, and that explicit setValue and getValue methods will be written. I’ve been exploring removing that interface, but I’m still trying to understand the implications of that. After tell the Editor to then ignore some properties it would otherwise try to “bind” with the Editor framework (which made sense to set the Editor.Ignore annotation on), it runs, but doesn’t seem to “fix” the problem and actually instead seems to make it so that the add/remove from the collection no longer propagates to the server. I’m guessing because The LeafValueEditor is the only interface where the getValue() method will be called to return the revised collection.

2. (regarding this next point, it might have an interplay with #1, but I’m not sure) It seems that GWT 2.3 had a bug where the RequestFactoryEditorDriver doesn’t correctly propagate the RequestContext to subeditors within a ListEditor. They claim to have gotten the fix into GWT 2.4 which I am running. I even confirmed that against the GWT svn repository, and double checked against the source code included in the GWT 2.4 plugin installed by the Google Plugin for Eclipse. So, that research path hasn’t clarified things, but it seemed very relevant. Here is the GWT issue tracking that: http://code.google.com/p/google-web-toolkit/issues/detail?id=6081

Regarding #2, I enhanced the two class definitions to contain the HasRequestContext interface

public class PaymentSetEditor extends Composite implements
ValueAwareEditor<Set<PaymentProxy>>, LeafValueEditor<Set<PaymentProxy>>,
HasRequestContext<Set<PaymentProxy>> { // new interface

class NameLabel extends Composite implements ValueAwareEditor<PaymentProxy>,
HasRequestContext<PaymentProxy> { // new interface

and implemented the necessary interface method, and I clearly see a “valid” RequestContext set on the PaymentSetEditor, but a NULL RequestContext is being set into the NameLabels generated by the ListEditor. This seems to be exactly what was suggested in that GWT issue, and even after I worked through removing LeafValueEditor (as described in #1 above), I still saw NULL RequestContexts set on the ListEditor’s NameLabel editors.

I attached my workspace, but had to delete the following files to keep the attachment size down:
* NestedEditingInGWTScaffolding-Compacted\gwt-unitCache
* NestedEditingInGWTScaffolding-Compacted\WebRoot\WEB-INF\lib\gwt-servlet.jar
I also included a breakpoint export to flag the key points.

Any help would be appreciated. And please let me know if this is the wrong place to be posting this. I imagine I will likely start trying to build a bottom-up reproducible case next without Scaffolding in the picture.

Pete

Attachments:

You must be logged in to view attached files.

[pjaffe]

I think this is starting to become a little clearer in my mind, but not enough to see a direct path through yet…

My hunch at the moment is that I need to look a level higher at the approach scaffolding took to rendering child collections, because it may just not be conducive to editing them. It seems the “root” RequestFactoryEditorDriver is created in the AbstractProxyEditActivity.start() which invokes CustomerEditView.createEditorDriver() to actually create the driver and initialize it, and then RequestFactoryEditorDriver.edit() is invoked with the save RequestContext wired into it. Then, the PaymentSetEditor() constructor ends up creating the ListEditor but also creates its own RequestFactoryEditorDriver which never has edit() invoked on it… and I generally assume I wouldn’t want two separate RequestFactoryEditorDriver instances when I am trying to conceptually think of a single hierarchical editing experience for the complete object graph (in this case, just Customer and its Payments).

Anyway, this follow-up post is mostly to say that I am now leaning toward thinking my points #1 and #2 above are likely downstream considerations, and maybe aren’t even issues at all. And that they instead may just be a result of the upstream design put in place by scaffolding which I just need to figure out how to rework with the goal of trying to rewrite as little of the scaffolding design as possible, least I start to regret having used it as a launching point.

Anyway, I worry this forum post is turning into just a “help me figure out how to twist GWT scaffolding into a hierarchical editor which it may not have been meant to be in the first place”, but I can still be optimistic someone might be able to point me in the right direction 🙂

Pete

[cconway]

Hi Pete,

It would seem that what you are trying to do is reasonable but is unfortunately beyond the scope of what I can help you with from a support perspective.

Perhaps another developer more familiar with the mechanisms in GWT can chime in and offer suggestions.

[pjaffe]

I’m not surprised by your answer, but thanks for taking the time to read my post.

I spent more time with it, and at least convinced myself that hierarchical editing of 1-to-many collections is completely supported by RequestFactoryEditorDriver, and I created a MyCollectionEditor that implemented the IsEditor<ListEditor<MyObjectInTheCollection, MyObjectEditor>> and encapsulated a ListEditor in that, and it all worked exactly as expected.

I imagine I’ll try tearing out the PaymentSetEditor-style implementation that Scaffolding builds for the related entities, and replacing that with a what seemed to be a pretty clean and straightforward implementation. So, I would still be curious why the Scaffolding design went the direction it did for that lower level editor. Hopefully not due to some good reason that I am going to stumbled into before too long 🙂

BTW, I’ve also found that the default implementation of the GWT Scaffolding application does push a modified root object to the server along with the addition or removal of related objects, however, the persistence implementation appears to not add/remove the related objects. I didn’t spend any time digging into that, so this paragraph is just to give you a heads up about a likely bug in that default implementation.

Pete

[Author]

Posts