what kind of MVP to use, what is "current" best practice

[tanteanni]

first i thought it is hard to decide which front end/ widget framework to use (i decided to use pure gwt because of flexibility) but now after writing first small prototypes and reading about "best practices" and MVP, i came to conclusion that the much harder decision is how to implement MVP or how the backbone of my app would/should look like.
Currently i implemented my like this "Large scale application development and MVP" and had problems to get the view humble enough (gwt discussion). But digging deeper led to MvpActivitiesAndPlaces (at first sight this isn't "pure" MVP anymore?! it feels like a contradiction to MVP wit humble views?!) but i dug even deeper and found GWTP and Errai. I also found articles about dependency injection and Gin/Guice and that this should be a part of a "good" Gwt-App (google-web-toolkit-gwt-mvp-example). are frameworks that include dependeny injection preferable?
So how to construct the backbone of my app? how comparable (or probably "combineable") are this 3 "frameworks". Is "Large scale application development and MVP" out of date?


(the application i am about to construct is a large scale (at least the budget is large) -public - statistical data - presenting - web-application)

[Thomas Broyer]

I started using the approach of "part 1" 2 years ago (after Ray Ryan's famous talk at I/O) and switched to the one of "part 2" soon after (a couple months or so). It puts a bit more logic into the view, but makes the code oh so more readable and testable (you just have to mock your view vs. many HasXxxHandlers/HasText/Focusable/etc.)

I started using activities almost a year ago, as soon as they came out in 2.1-m1 and I don't regret it. Activities however are in no way related to MVP: you can use activities without doing MVP, and you can (and you probably will if your UI is complex) do MVP outside activities.

None of these approaches to MVP is outdated. Choosing one or the other is mostly a matter of taste, and how much logic you're ready to push into the view (even though "part 2" way doesn't necessarily implies a less dumb view; but "part 1" way kind of enforces it OTOH). And both approaches can be used with activities.

Now that I use them extensively, I couldn't live without MVP (to decouple presentation logic –including "service calls"– from the view), places and activities (for navigating in the app, and "compositing the screen"), dependency injection (it simplifies the code so much!), and the Editor framework (to display and/or edit objects).

YMMV but that's my combo for success.

[Ernesto Reig]

Hi all,

Reading your two posts, and if it helps you (tanteanni) to be more confident if you have two opinions encouraging the same approach, I will say that I completely agree with Thomas: "I couldn´t live without MVP" once I have understand it and know its advantages over other design patterns (architecturally speaking). Having a dumb view and leaving the logic decoupled gives you (and/or your team) power and efficiency, therefore time-saving development, when it comes to develop large applications.

But Thomas, there´s something I don´t understand, when you say "Activities however are in no way related to MVP". Activities are the Presenters in the MVP pattern, I mean, they own the views and there happens the logic decoupling. The views talk/notify the Activities when some user action that needs logic happens. Activities are responsible to talk to the server, send and retrieve data, goto() other Place´s, and therefore keeping the views "dumb". So, when you say that Activities are not related to MVP I can only think that I´m missing something...

Could you please shed a bit of light on this? :)

Thank you

[Jens]

I am also using the MVP approach described in "Large scale application development and MVP - Part II".

It is really nice to have a delegate interface that is known to the view and is used to delegate UI events to methods. The view can then use UiBinder's @UiHandler and can also do simple logic before calling a method on that delegate interface (Part 2 calls this delegate interface presenter). This simple logic may be something like "If the user clicks on the 'add date' button then the date textbox should not be empty and contain a valid date, otherwise show a Window.alert message" or something like "If the user checks this checkbox then disable textbox x, y and z". Its really annoying to have these kind of simple checks inside a presenter that already contains the heavy logic and service calls.

That way there is nearly no need for lots of methods that return HasXxxHandlers, etc interfaces and you do not have lots of anonymous classes just to bind your presenter to the view.

The "GWT MVP" with Activities and Places is more a History Management Framework so you can use the browsers back/next buttons and to make states of your app bookmarkable. So you could use "GWT MVP" along with the MVP pattern described in "Large scale application development and MVP - Part II" or with any other MVP pattern.

So I would choose:

- GWT MVP, if you want your app states bookmarkable (along with back/next browser button support)

- MVP Part 2, if you use UiBinder and you do not want lots of HasXxxHandlers methods in your view and anonymous classes in your presenter (and you like the idea of pushing some logic into the view)

- Editor Framework, if your app often edits data and you want to reduce the amount of code you need to copy data from model objects into the view and then back to the model.

-- J.

[tanteanni]

thx for explicitly pointing to "part2" - 'til now i didn't read it because i thought it is all about how to use uiBinder but now i found "...you quickly realize that something has to give. Either the presenter needs to know more about the view (making it hard to swap out views for other platforms), or the view needs to know more about the data model..." there. So the question most hurting me at the moment is answered :-).
BUT: I am confused (like many others - a search for "MVP" in this group revealed) about statements  like "Activities however are in no way related to MVP" and "This article looks at Activities and Places in GWT 2.1, which relate to the presenter and view aspects of MVP." (from (i know you know it and i guess you guessed i will mention it): DevGuideMvpActivitiesAndPlaces  - on first sight the "view" there differs from "part1" and "part2"?) .
So the Question is how both concepts relate or how they could be put into a relationship within an GWT-App? Or how a "best practice" would construct views, presenters, places, history, server communication? (a simple union of "part1"- "part2"- and "ActivitiesAndPlaces"- Article would have contradictions, wouldn't it?)

the third part of my question drifted in background somehow: is it a good idea to achieve MVP with some framework (gwtp, mvp4g...)? my first idea on this was to keep my app "framework free" as long as possible - (analog to my decision about widget frame works). But both p frameworks promise "more app" with less code ?!

[Jens]

Am Mittwoch, 27. April 2011 13:32:47 UTC+2 schrieb ernesto.reig:

But Thomas, there´s something I don´t understand, when you say "Activities however are in no way related to MVP". Activities are the Presenters in the MVP pattern, I mean, they own the views and there happens the logic decoupling. The views talk/notify the Activities when some user action that needs logic happens. Activities are responsible to talk to the server, send and retrieve data, goto() other Place´s, and therefore keeping the views "dumb". So, when you say that Activities are not related to MVP I can only think that I´m missing something...

Could you please shed a bit of light on this? :)

I am not Thomas but an activity is only responsible to put the correct widget into a display area you have previously defined. There is no need that an activity controls that widget. An activity can also have an instance variable holding a presenter and then get the presenters view and add that to the display area. So an Activity can be a Presenter.. but it do not have to. In my understanding an activity is more abstract than a presenter. Its something that starts when you visit a place and that is responsible to fill a display area on your website, but its not responsible for handling user UI events (but it could if you want to). Thats why GWT MVP is somehow a misleading term.

[Ernesto Reig]

Thank you Jens,

I understand what you have said. Well, the thing is that I have used the Activity as a Presenter in all my web apps (putting a Presenter object in the view, implementing the presenter interface in the Activity and setting this as the Presenter of the view) and I haven´t think of having a separate implementation for the presenter and another one for the Activity. Are there any advantages of doing it this way? I am thinking about that...

[Jens]

Good question. I haven't done a web app yet that uses activities/places, so I have only read a lot about it.

But if you have a token like #ListPersonDetailsPlace:1  to list details of a person with database id 1, an activity could load that person from the database and set it to the presenter it holds a reference to. That way an activity does the heavy work for restoring the application state defined by the HistoryToken and then configures the presenter and finally adds the presenters view to the display area. That way the presenter does not have to load anything to actually work and would only react to UI events and perform its logic (which could be already be lots of code) and the activity is responsible to configure the presenter and put it into the correct state.

But maybe someone with more practically knowledge could give a better advise/example. 

[Thomas Broyer]

On Wednesday, April 27, 2011 1:32:47 PM UTC+2, ernesto.reig wrote:

But Thomas, there´s something I don´t understand, when you say "Activities however are in no way related to MVP". Activities are the Presenters in the MVP pattern, I mean, they own the views and there happens the logic decoupling. The views talk/notify the Activities when some user action that needs logic happens. Activities are responsible to talk to the server, send and retrieve data, goto() other Place´s, and therefore keeping the views "dumb". So, when you say that Activities are not related to MVP I can only think that I´m missing something...

Could you please shed a bit of light on this? :)

That's generally how you'll do it, but nothing in the Activity contract enforces it. Need a proof? Here it is in 15 LOCs:

public class ActivityWithoutMvp extends AbstractActivity {

  @Override

  public void start(AcceptsOneWidget panel, EventBus eventBus) {

    FlowPanel container = new FlowPanel();

    final TextBox textBox = new TextBox();

    container.add(textBox);

    container.add(new Button("Say hello!", new ClickHandler() {

      @Override

      public void onClick(ClickEvent event) {

        Window.alert("Hello " + textBox.getText() + "!");

      }

    }));

    panel.setWidget(container);

  }

}

You could also extend, say, Composite while implementing the Activity interface. That'd work too.

It'd be in most case a brad practice as it violates the "separation of concerns" pattern, but for very simple activities (such as the above) I think it's OK not to use MVP.

[tanteanni]

my confusion is raising?! (did someone read my "answer"? i kindly ask that someone may pay attention to it)
thomas i don't know if i understand the relation (i it exists) between MVP and places and activitie? "It'd be in most case a brad practice..." does this mean that is bad practice if places and activities don't have an relation to MVP in an given application? (and how does this relate to " Activities however are in no way related to MVP"?).
at the moment i see an activity as an 3rd place to put logic in: "part1" says put all logic in presenter, "part2" says at some (use) cases logic in view is ok(is this: gwt discussion such a use case?), jens and thomas say history/state logic could be sperated from presenter and put into activity ??
(besides how good is the the history handling of part1 ? is "at least" this part out of date and it is better to use places and activities?)

[Thomas Broyer]

For anything "history related", I highly recommend using places. For "compositing your screen", based on the current "place", I highly recommend using activities.

I highly recommend using MVP too (using the "part 2" approach, where the presenter knows the view, and the views knows the presenter in return), where your activities will be your presenters; but activities and MVP are different concepts.

Shameless plug:

1. Places:
1. http://tbroyer.posterous.com/gwt-21-places
2. http://tbroyer.posterous.com/gwt-21-places-part-ii
2. Activities:
1. http://tbroyer.posterous.com/gwt-21-activities
2. http://tbroyer.posterous.com/gwt-21-activities-nesting-yagni

[tanteanni]

Thx to all of you, confusion is disappearing (slowly) :-)
So the bottom line is: a good practice would be to use MVP ("part2" -Way) in conjunction with "places and activities"(mainly for history management - ignoring history management of "part1" - but also as a more abstract kind of presenter(activity part)) ?

Is it possible (or probably preferable) to "aid" the implementation of MVP by a MVP-Framework (like those mentioned above)? or would this raise some conflicts with gwt's places and ativities?

[Ernesto Reig]

Personally I don´t like using other frameworks to aid with the MVP implementation. I would use Activity´s and Place´s but using the MVP philosophy, i.e., the Activity acts as the Presenter of the view also. It holds the view. The view has a Presenter object (the interface that implements the Activity). When the Activity start()s it sets the Presenter in the view (itself).

If need sample code, just ask, ok?

[Ernesto Reig]

Well, I was not asking for a proof, but thanks anyway :) I know it is possible to do that, the Expenses sample works that way...

I was just wondering why you were saying that Activity´s don´t have anything to do with MVP, cause they are the backbone of my MVP implementations (they are the Presenter´s). But now I see the point, you can use Activity´s without "architecting" your app in the MVP way. You could have, for example, in the Activity a Presenter object (the implementation), the view object, and just set the the presenter object as the presenter in the View.

It´s just that it does not make sense to me having an MVP designed app without using the Activity´s as Presenter´s. If someone has any reason to use another object (not the Activity) as the Presenter to make an MVP app, please tell me why.

[Jens]

As you are a bit confused how things play together I think it would be the best to go without a MVP Framework for now. Create a small example app using places and activities along with some Ui components that are implemented using the MVP part 2 approach. You can also integrate Gin (and maybe Guice) so you have dependency injection (which is really nice). Once you understand all these you can take a look at the mentioned MVP Frameworks and decide if they could help you or not (and if you like them or not).

But in general I think you can use what ever MVP Framework you would like to use. Shouldn't be a big problem with activities.

[Thomas Broyer]

On Wednesday, April 27, 2011 4:55:06 PM UTC+2, tanteanni wrote:

Is it possible (or probably preferable) to "aid" the implementation of MVP by a MVP-Framework (like those mentioned above)? or would this raise some conflicts with gwt's places and ativities?

GWTP and Mvp4g both do much more than just "MVP" (because you really don't need any kind of framework for MVP: just create two interfaces, two implementations of those interfaces and you're done; the hard part is the lifecycle of your "components", and how you "plug" them together, and this is where activities, GWTP and Mvp4g chime in), so they indeed "conflict" with the activities framework (that's the deal with frameworks vs. toolkits/libraries).

In the end, you'll have to choose one of them three. My choice is activities, but YMMV, and both GWTP and Mvp4g are very good frameworks (made by really nice and skillful guys). It's just that I don't like frameworks, and "activities" is so lightweight that it's hardly more than a toolkit: if there's a part of it you don't like, you can very easily replace it with your own, because you still have to do the bootstrap yourself (contrary to most said "frameworks"; see, with GWTP your EntryPoint is almost empty, and with Mvp4g you don't even have your own EntryPoint!)

[Gal Dolber]

As everyone already said, gwt places/activities is a history management implementation, gwt at the moment doesn't include any mvp implementation. That doesn't mean that the way to go with mvp is by-hand. I am sure that if in the future gwt would include GWTP or any other framework everyone would use it, you just need a little push from google.

Mvp is a great pattern, but is incredibly full of boilerplate code. If anyone used DI before without guice(or any other) I think the case is the same. Doing hand-written mvp will generate small mvp frameworks on each developer/company, cause I asume you actually don't like to write boilerplate code. That's not a bad thing, but we won't have any standard till google says what framework to use or they make their own.  

Don't get me wrong, if I start using gwt today the first thing I'll try is activities/places and I won't touch any framework until I really need it, same thing happened to me with appengine and jdo, I really hated learning and using jdo but I had to try it, google's tutorial used it... then I found objectify and slim3 and my life was much much easier.

Anyway, I bring another player to the table: guit

You are all invited to try it!

Regards

--
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.

--
Guit: Elegant, beautiful, modular and *production ready* gwt applications.

http://code.google.com/p/guit/

[tanteanni]

thanks to all of you!

all of you suggest the same way (rarely enough :-)): try to work with the tools offered by gwt and use them the way they meant for. and obey to MVP!(the only part i tried already)
(should gin/guice also remain "untouched"?) do you use gin/guice?

so i'll read part2, read again Thomas' blog (thoroughly this time) and the places and activities article at google.

[Rodolphe Gomes]

I have used PureMVC (pureMVC.org) which was perfectly adapted for my EXT / GWT / Hibernate application.

I used Dozzer for mapping entity to pojo and @BEAN annotation (BeanModelMarker) to tell GXT to adapt with beanModel GXT.

I know that Seesmic (http://seesmic.com/) has also used this library.

[1] My view with no logic, only getter and setter:

  public class UserList extends LayoutContainer

  ....

  public void setGridContent(final List<BeanModel> stocks) {

    grid.getStore().add(stocks);

 }

  ...

  public BeanModel getSelectedRowObject() {

    return grid.getSelectionModel().getSelectedItem();

  }

[2] Mediator with generic UserList

  public class UserListMediator extends Mediator<UserList>

  @Override

  public final String[] listNotificationInterests() {

    return new String[] {

      ApplicationFacadeConstants.NOTIFICATIONS.USERS_LOADED.name(),

      ApplicationFacadeConstants.NOTIFICATIONS.FAIL_LOADING_USERS.name()

    };

  }

  public void handleNotification(final INotification notification) {

    super.handleNotification(notification);

    final NOTIFICATIONS notificationEnum = ApplicationFacadeConstants.NOTIFICATIONS.valueOf(notification.getName());

    switch (notificationEnum) {

    case USERS_LOADED:

  public void handleEvent(final BaseEvent be) {

  final EVENTS event = ((Component) be.getSource()).getData(IConstants.EVENT);

  switch (event) {

  case ADD_USER_BUTTON_CLICKED:

          break;

  case ROW_USER_SELECTED:

        final BeanModel selectedItem = getViewComponent().getGrid()

            .getSelectionModel().getSelectedItem();

        logger.log(Level.INFO, "Row selected........." + selectedItem);

        break;

  public final void onRegister() {

  initView();

  super.onRegister();

  getViewComponent().getGrid().addListener(Events.RowClick, this);

  getViewComponent().getDeleteButton().addListener(Events.OnClick, this);

  getViewComponent().getNewButton().addListener(Events.OnClick, this);

[3] Proxy to manage list and selection

public class UserProxy extends Proxy 

// the row selection

UserDTO getSelection()

// all the rows

List<UserDTO> getData()

...

Rodolphe

[Magno Machado]

>(should gin/guice also remain "untouched"?) do you use gin/guice?

Dependency Injection is a concept which doesn't depend on MVP.

You can try it with no framework, but soon you'll give up :)

--
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.

--
Magno Machado Paulo
http://blog.magnomachado.com.br
http://code.google.com/p/emballo/

[Michael Prentice]

Thank you very much for this discussion. I found it very helpful in clarifying Activities, Places, and MVP.

I've got my server side architecture figured out mostly (other than Guice/DI). Now this helps me to put into place my client side architecture (other than GIN/DI).

Now I just need to spend some more time wrapping my head around DI and how exactly to make it work for my project. I've looked at most of the examples on the GIN and Guice project pages but I just haven't really been able to tie them into my project cleanly yet. Perhaps it will be easier for me to do on the client side while using MVP + Activities and Places.

[Xybek]

On 04/27/2011 03:47 PM, tanteanni wrote:
> first i thought it is hard to decide which front end/ widget framework
> to use (i decided to use pure gwt because of flexibility) but now after
> writing first small prototypes and reading about "best practices" and
> MVP, i came to conclusion that the much harder decision is how to
> implement MVP or how the backbone of my app would/should look like.
> Currently i implemented my like this "Large scale application
> development and MVP"

> <http://code.google.com/intl/de-DE/webtoolkit/articles/mvp-architecture.html>

> and had problems to get the view humble enough (gwt discussion

> <https://groups.google.com/d/topic/google-web-toolkit/3wqCUQpz2d4/discussion>).

> But digging deeper led to MvpActivitiesAndPlaces

> <http://code.google.com/intl/de-DE/webtoolkit/doc/latest/DevGuideMvpActivitiesAndPlaces.html>

> (at first sight this isn't "pure" MVP anymore?! it feels like a
> contradiction to MVP wit humble views?!) but i dug even deeper and found

> GWTP <http://code.google.com/p/gwt-platform/> and Errai
> <http://www.jboss.org/errai>. I also found articles about dependency

> injection and Gin/Guice and that this should be a part of a "good"
> Gwt-App (google-web-toolkit-gwt-mvp-example

> <http://blog.hivedevelopment.co.uk/2009/08/google-web-toolkit-gwt-mvp-example.html>).

> are frameworks that include dependeny injection preferable?
> So how to construct the backbone of my app? how comparable (or probably
> "combineable") are this 3 "frameworks". Is "Large scale application
> development and MVP"

> <http://code.google.com/intl/de-DE/webtoolkit/articles/mvp-architecture.html>

> out of date?
>
>
> (the application i am about to construct is a large scale (at least the
> budget is large) -public - statistical data - presenting - web-application)
>

> --
> 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.

I use GTWP (GWT Platform) I find it easier than the MVP bundled with GWT
(personal opinion though...)

Anyway, it's your call I think when we say MVP then most likely it use
IoC pattern of some sort.

So if you're like me that want to keep my gwt core code as lean as
possible and just use 3rd party for mvp you can try GWTP, but if you
want to keep things intact (w/o 3rd party) then the native MVP is the
choice...