BestPractice : Use of the Editor Framework with MVP (Place, Activity) and RequestFactory

[Patrice De Saint Steban]

Hello,

I want to have the best practice to know how to use the Editor Framework with MVP. Where place all the code.

For exemple if I want to  do a build an Activity with edit an object, I will create first an Activity EditObjectActivity and a EditObjectView interface with the EditObjectViewImpl that use the UiBinder.

The first think is to load the object to edit with RequestFactory. I put this code in the start method in the Activity.

After I must create the Driver :

public interface Driver extends RequestFactoryEditorDriver<ObjectProxy, EditObjectViewImpl>

{ }

The creation of the Driver

driver = GWT.create(Driver.class);

driver.initialize(view);

Bind the object and the persit request to the driver :

objectRequest = clientFactory.getAppRequestFactory().objectRequest ();

driver.edit(object, objectRequest );

My Question, is where in the MVP put all these codes ?

The Driver must be pameterized with a Proxy P and a class extend Editor<P>.

The Driver is in the Activity ?

The activity mustn't know the implementation of the View and the driver must know it to generate the binding.

or the view must have all methode for all Editor implementation

Or the Driver can be in the View ?

Thank for the reply.

-- 

Patrice de Saint Stéban

Groupe SFEIR - France

[Bálint Kriván]

Hi!

I was facing the same issue. I've found out this, but I'm open to any suggestion:

I've put Driver in the Activity, because View should be responsible only for display (but using editor.flush() method is responsible for Model changes -- it should go to the Presenter layer (Activity in this perspective)).

Because Driver needs a class with the right properties, you can't let View implement the Editor, because it's simply not working (I've tried).

I've made a seperate Editor widget (with UiBinder), which is included in the View, and I've made a getEditor(); method in the View interface, so Presenter can get the Editor from the View.

My only problem, that I have to make an other Composite for the Editor, but it would be great to include it in the View, but I couldn't. Any advice are welcome, maybe there is a better solution.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
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.

--
Üdv,
Kriván Bálint

[nacho]

Google People, what do you recommend if we want to use MVP & Editor Framework togheter?

[Thomas Broyer]

FWIW, we simply copied what they did in the Expenses sample, and we're happy with it: add a createEditorDriver in your view (that the presenter will call) and do everything else (edit, flush, etc.) in the presenter.

The createEditorDriver method does the GWT.create and the .initialize().

[Patrice De Saint Steban]

Thanks Thomas,

I haven't think to this solution, and it's a good solution.

On Thu, Jan 27, 2011 at 00:11, Thomas Broyer <t.br...@gmail.com> wrote:

FWIW, we simply copied what they did in the Expenses sample, and we're happy with it: add a createEditorDriver in your view (that the presenter will call) and do everything else (edit, flush, etc.) in the presenter.

The createEditorDriver method does the GWT.create and the .initialize().

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
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.

--
Patrice de Saint Steban

pat...@desaintsteban.fr

06 74 11 63 02

[nacho]

Great

[Y2i]

Thomas (and GWT team)

If a view is a singleton (as recommended by MVP), are there potential memory leaks with this approach?   When a second driver is created and initialized, does the first driver become completely detached from the view/editor?

Thanks for the advice.

[Colin Alworth]

For my part, I've not been creating a 'createEditorDriver()' method, but instead 'getEditorDriver()'. This way, there is no concern about binding and traversing the tree more than once.

Am I in error with this approach? Each time my presenters get a ref to the driver and have finished loading data, they call driver.edit (or .display) which should get rid of the old requestcontext, set up a new editor delegate, etc. The existing eventbus/factory should still be good.

The only concerns I had were for events that might have already been wired up, say from something implementing HasEditorDelegate, but it should be the implementing class's responsibility to clear out old registrations... Okay, so when (in either case) should those be cleared out? When setDelegate is called again? But what if it isn't called again – then do those subscribed events just keep going off? Or maybe take them out on .flush(), since you know then that "the Editor cycle is finished"?

[Thomas Broyer]

On Tuesday, February 8, 2011 2:51:23 AM UTC+1, Y2i wrote:

Thomas (and GWT team)

If a view is a singleton (as recommended by MVP), are there potential memory leaks with this approach?

Yes, but not related to the Editor framework (only to the fact that a singleton will still exist until the page is unloaded, even if you no longer use it; this means that the singleton approach might not be appropriate for all views: if a view is displayed early but you know it has little to no chance of being displayed later –e.g. a "welcome" or "what's new" screen– it might be better to not make it a singleton: you'll "pay" again for building a new one when needed, but on the other hand you'll free memory).

 

When a second driver is created and initialized, does the first driver become completely detached from the view/editor?

A driver (and its delegates) is never attached to the view/editors. The delegates can be (if an editor implements HasEditorDelegate), as well as the EditorChain (used by CompositeEditor-s), but if your editors don't retain references on those instances, there won't be memory leaks (the next driver will pass its own instances).

Note that in 2.1.x and 2.2.x there's actually a "leak" if you re-use the same driver for several edit() with different objects (the DelegateMap is created once and never cleared; EditorDelegate-s are created for each call to edit() and put in the map, associated with the edited object).

Looking at the code in trunk (GWT 2.3), the EditorDelegate-s are created once on initialize(), and the DelegateMap is only used in setViolations/setConstraintViolations; so it seems to me like there's no longer such a potential leak.

[Thomas Broyer]

On Tuesday, February 8, 2011 3:18:46 AM UTC+1, Colin Alworth wrote:

The only concerns I had were for events that might have already been wired up, say from something implementing HasEditorDelegate, but it should be the implementing class's responsibility to clear out old registrations... Okay, so when (in either case) should those be cleared out? When setDelegate is called again? But what if it isn't called again – then do those subscribed events just keep going off? Or maybe take them out on .flush(), since you know then that "the Editor cycle is finished"?

Or should you rather pass a ResettableEventBus to initialize() ? (for instance, the one passed to your Activity, which would scope an EditorDriver instance to an Activity, rather than scoping it to the view)

[Y2i]

Thomas, thanks for the detailed response! I was actually re-using drivers for several edits (similar to Colin I guess), will be switching to your (and Expenses') approach.