Is there a set of best practices for implementing nested presenters/view?

[Mohammad Al-Quraian]

I did my own way of nesting presenters and now I hit a design issue, should the nested presenter have a reference to the nesting presenter? Is there a better design than this?

[coderinabstract]

Consider gwtp (gwt platform) an open source MVP framework for GWT which solves this problem very elegantly... Cheers.

[Ed]

I wouldn't use these MVP patterns like gwtp before understanding well the different View patterns, start reading here:

http://martinfowler.com/eaaDev/SupervisingPresenter.html (martin fowler).

Every situation is different, and "simple" adding a tool like gwtp might not work for you, even worse, might result in awkward buggy code.

If you understand well the theory, you can always use (parts)  these framework, but to my experience, if you understand well the patterns, you will not use them (anymore) and make things yourself as it's not a lot of coding.

Personally I don't think I would use nested presenters, I did that in the past, but didn't like it. I use kind of Autonomous views -> All my widgets  extend from lightweight IsWidget objects that construct the actual Widget (builder pattern). I have good experience with it, like and results in good unit testing (I wrote something about that some time ago in this forum).



Op woensdag 10 april 2013 01:30:55 UTC+2 schreef Mohammad Al-Quraian het volgende:

[Mohammad Al Quraian]

Yeah, I don't have any intentions in using any more frameworks. Let me ask you this, let's say that you have a page which has multiple panels and in each panel there are multiple widgets. How would you go about implementing that yourself? I'm especially interested in the case that you wanted for some of these widget to communicate with each other.

In my design, I made a 'father' presenter that has a few 'children' presenters, the idea here is that these presenters can communicate with each other directly (father to children and vice versa), with the father having the overall control. Of course, each presenter controls its own view and nobody knows about this view.

Isn't that a good way of handling things or is it complicated?

--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/cfj3qqhufKc/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ed Bras]

Let me give you some idea's from what I use now, and which I like after trying/playing many things in the last 7 years with gwt:

+ Well defined overall functionality, like login, productInfo are contained in a component. The component has a Controller, View, if required a Presenter and always a Facade. 

The facade hide's all internal things and is the class that others use to communicate with the component. 

This setup has many advantages like clear, pushing events instead of pulling to overcome a Handler web that results in memory leaks, good unit testable as all required things like presenter, controller, view, widgets... etc.. are created through the facade and the facade is mocked through the GWTBridge during unit testing.

+ All controllers are lazy loaded through code splitting and hold in a central controller storage.

+ The View composes widget, not more, not less and take care that it keeps this responsibility during development as developers often put too much widget things in a view such that the view's become messy and hard to test.

+ In the View you use hardcore OO design and use things like HeaderPanel, ProductContainer, Product, StatusButton, etc...

I can't stress enough the "OO design", as if you do, you will see that flow's and coding becomes logic and stays maintenable such that it's easy and natural to add functionality. 

Yes, you probably complain that you get a lot of small objects, and the code often takes longer to understand,  but that's OO, but the advantage of optimal reuse of small pieces of functionality.

+ Use standard patterns like factory, singleton, visitor, service, builder patterns, such that others can more easily understand the code.

+ Use lightweight widget (builders) that extend from IsWidget (ProductContainer extends from IsWidget), that contains logical and can easily be tested.

+ If these widget (builders) need to communicate with eachother I use a Communicate interface (or Informer interface) that is public but contained in the Widget itself. I't s usualy injected throug the constructor and required.

+ The Composer (father in your story) implements mostly all Communicator interfaces and delegates it to others, like: bubble it up to the controller, or let another widget do something.

It all depends on the responsibility of every widget/component.

For example: in my case, only the controller is allowed to communicate to the backend, such that only the controller contains Async callbacks.

+ Use a lot of Characteristic interfaces like HasId, HasEmpty, HasSize (just like GWT does), as this makes coding a lot easier as the Communicators are basically composed of these smaller interfaces...

+ The number of if conditions and static methods is a measurement for your OO coding. The more if statement, and static method usage, the less your are coding OO (this comes from  the OO books).

Anyway: I often use Singleton classes instead of static utility classes. The nice things of these singleton classes  is that you can change their implementation through deferred binding.

Example: CmsKeyNames that contains all cms keys, or CmsFactory (factory pattern).

Too often I started with static methods and then needed other return value's under certain conditions (other app), which is hard when using static method as you can't do anything with it.. Changing them can be a pain.

+ etc....

Yes, it all results in more coding... but that's why people often complain that Java is a very verbose language ;) Especially when you want to correctly code OO.

Above setup is especially friendly for long running app's that need to be changed in such a way that it stays maintenable and changes don't become too expensive.

Above just came up, which I think contains some things you can use.

Good luck.

[Mohammad Al Quraian]

Wow, that's a lot to digest, I need some time for that. Thank you very much. Just a quick Q, controllers, views, presenters and facades are all different things?

Also, wouldn't you consider facades a form of presenters? If not then what is the difference?

I really like your input and hope more people contribute to this discussion.

Thansks

[Ed]

Just a quick Q, controllers, views, presenters and facades are all different things?

Yes, different.

Facades have nothing to do with presenters, controllers in this case.

Facades are just stupid things that form the central access to "something", in my case: the component.

I use the component facade for example:

1) To create the controller, view, presenter, etc.. as the facade is mocked during testing such that I can inject mocked controllers/views/widgets/

2) App flow methods, for example the method HeaderMenuFacade contains the method afterSuccessLogin(String), such that it get informed by another component, like the LoginFacade, that a login with was performed with success. The HeaderMenuFacade now delegates this to the controller ( if loaded), such that it can update the header menu...

[Ed]

One more things that popped up:

+ Use WidgetDisplayer interface with methods like show(IsWiget) (or multiple widgets) and isShowing(IsWidget).

This is used by the Views to show their content, such that you abstract the location (and how) it's content is shown.

You often specify these WidgetDisplayers through the constructor such that the creator (Component facade) decides how/where something is displayed.

I found this very nice and it results in flexibiltiy when you want to change the display and you don't need to touch the views.

In this way you can easily use different WidgetDisplay implementations for different displayes like a mobile or desktop web display.

I have DisplayFacade (a singleton ofcourse) that contains all the WidgetDisplay implementations. It's located in it's own package and all WidgetDisplay implementations are packages protected, together with a HtmlConnector that determines the locations on the html display.

I almost always show my content through animation, like Fade In and Fade out (nice user experience) which you can nicely put in these WidgetDisplayers (or HtmlConnector)...

Works like a Charm...

.... (and the story continues ;) )

just my 50 cents...