Activities&Places : Custom Composite inside a view (design question)

[Jonathan Aubuchon]

Hi, I'm a beginner with the architecture MVP Activities and Places.

Suppose I have two views: View1 and View2
(The two views have their own activity)

Now suppose that I have one Composite (named Composite A) used by the
two views. This Composite aggregate a textbox, display informations
and make call to the database.

Should I plug an activity over this Composite ? (In order to move the
logic and database calls inside an activity instead to do that inside
a view).


I tried the activity solution and this is the steps I did:

1) Create a new activity and place for the CompositeA. Move some
logics and database access inside it.
2) Create a container (SimplePanel) inside the View1 and View2 to
hosted the CompositeA
3) Inside the activity of View1 and View2 (in the start method) , I
instantiate the activity of the CompositeA and start it:

ActivityCompsiteA activityCompositeA = new ActivityCompositeA(new
ActivityCompositeAPlace(" "), clientFactory);
activityCompositeA.start(view1.getContainerForCompositeA(), eventBus);

It works fine, but maybe it exists a conventional way to do it?

Thank you

[Thomas Broyer]

On Monday, June 6, 2011 3:08:58 AM UTC+2, Jonathan Aubuchon wrote:

Hi, I'm a beginner with the architecture MVP Activities and Places.

Suppose I have two views: View1 and View2
(The two views have their own activity)

Now suppose that I have one Composite (named Composite A) used by the
two views. This Composite aggregate a textbox, display informations
and make call to the database.

Should I plug an activity over this Composite ? (In order to move the
logic and database calls inside an activity instead to do that inside
a view).

A presenter, yes. An activity, probably not (YMMV).

 

I tried the activity solution and this is the steps I did:

1) Create a new activity and place for the CompositeA. Move some
logics and database access inside it.

Why would you need a Place? the "activity" is supposed to be shown when the other activities (the one acting as presenters for View1 and View2) are; you're at the "same place" as those activities then (conceptually, the place is the "URL" for what you're seeing on screen)

 

2) Create a container (SimplePanel) inside the View1 and View2 to
hosted the CompositeA
3) Inside the activity of View1 and View2 (in the start method) , I
instantiate the activity of the CompositeA and start it:

ActivityCompsiteA activityCompositeA = new ActivityCompositeA(new
ActivityCompositeAPlace(" "), clientFactory);
activityCompositeA.start(view1.getContainerForCompositeA(), eventBus);

It works fine, but maybe it exists a conventional way to do it?

I'm afraid not.

We've used a similar pattern but didn't use an Activity for the nested presenter (because we don't need the lifecycle of the activity: we treat it just like any other component in the view, it's just a bit "smarter" than the others). We're putting the "composite" directly in the UiBinder template, and then we simply "wrap" the presenter around it (and just like any view, it's exposed as an interface, the composite being the equivalent of the "ViewImpl"):

class MyActivity extends AbstractActivity {

   private final MyView view;

   private final NestedPresenter nestedPresenter;

   @Inject

   MyActivity(MyView view, NestedPresenterFactory factory) {

      this.view = view;

      nestedPresenter = factory.create(view.getNestedComposite());

   }

   ...

}

(FYI, we're using GIN's @AssistedInject for the factory)

[Jonathan Aubuchon]

You are right, I do not need an nested activity/place but only a
presenter.

I imagine that inside your
NestedPresenterFactory.create(AcceptOneWidget container) you do those
actions:

1) you instantiate the nested view
2) you instantiate the nested presenter (and give it the nested view
instance)
3) you set the widget of the container [container.setWidget(view)]

is it right?

[Thomas Broyer]

No, the factory is only an interface, automatically implemented by GIN's AssistedInject. It only instantiates the presenter, passing the method arguments and a few others to the presenter's constructor (because in our app we inject everything in constructors).

What we pass as an argument to the factory is not a container for the view, it *is* the view.

[Jonathan Aubuchon]

Ok, thank you for your help Thomas Broyer!