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 <[email protected]>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 <[email protected]> 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 >> [email protected]. >> To post to this group, send email to [email protected]. >> 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 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 > [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. 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.
