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

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



 

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@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.

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@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.

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

[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


On Wed, Apr 10, 2013 at 11:49 AM, Ed Bras  wrote:

> 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.
>
>
>
>
> On Wed, Apr 10, 2013 at 9:35 AM, Mohammad Al Quraian 
> wrote:
>
>> 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 

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

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




On Wed, Apr 10, 2013 at 9:35 AM, Mohammad Al Quraian wrote:

> 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?
>
>
> On Wed, Apr 10, 2013 at 10:22 AM, Ed  wrote:
>
>> 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

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

[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?


On Wed, Apr 10, 2013 at 10:22 AM, Ed  wrote:

> 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:
>
>> 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?
>
>  --
> 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-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@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.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@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.

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

[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:
>
> 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?

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@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.

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

[coderinabstract]

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

On Tuesday, April 9, 2013 7:30:55 PM UTC-4, Mohammad Al-Quraian wrote:
>
> 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?

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@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.

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?

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@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.