A design pattern for widgets in the MVP - GIN - UiBinder paradigm.

[drthink]

Large scale application development and MVP :
http://code.google.com/webtoolkit/articles/mvp-architecture.html

I have a question on how you would extend this design to incorporate
complex widgets. The MVP pattern is very clear on how the separation
between the Presenter and View take place. A presenter defines an
interface which a view implements so the presenter can ensure that the
agreed necessary methods are implemented.

In the contacts example supplied by the article the idea is very
simple. The views do not have any complex widgets to display. But I
would guess for many applications each View is a page within the
application which is made up of complex widgets. So my first question
is:

Q1: Do you apply a separation of presentation versus view model to the
widgets as well or just build regular UiBinder widgets?

In the AppController a presenter is called with this kind of syntax:

presenter = new ContactsPresenter(rpcService, eventBus, new
ContactsView());

Q2: In a view that houses child widgets would I implement the same
kind of initiation, assuming the answer to Q1 is for a V-P model in
widgets.?

Q3 : If so how do we pass the rpcService eventBus to the widget
presenters?

These questions may seem kind of muddled, and as you can probably tell
I am just getting to grips with this concept. I have a feeling that
the answer lies in converting the example application to a incorporate
GIN which makes the widgets modular and therefore a lot of the
questions above become somewhat redundant.

Any thoughts would be much appreciated.

Cheers
DrJ

[Andrew Hughes]

I don't entirely understand everything you have said.... reading between the lines I think there's some information that could be helpful (but I might be wrong)....

Gin won't change your architecture or the MVP pattern, but it does drastically reduce boilerplate. A common problem with many patterns is that they are good in principle, but take a lot of (work) boilerplating the objects together. This boilerplating work often prohibits the application of a pattern because it becomes complex and is too much work.... let's just code around it ;) Not to mention maintaining/refactoring and debugging all that boilerplate.

So, when you are talking about forking away from MVP to VP and VV e.t.c. and "complex widgets" - it could be that the  boilerplating of MVP pattern seem unworkable for your situation, are you "coding around it" ;) But this is my ASSumption :) In our current app, sometimes parent/child view's talk directly to each other and presenters are often shared... it's not bad practice - just fit for purpose. We can easily separate view's with presenters are re-wire them with Gin if we need too.

There is at least one important caveat to this. The first cut of MVP said "view's should not have access to the presenter". This was not practical. Complex widget's like a table, or hierarchy of dynamic parent/child widgets had to be dealt with by code in the presenter to work with these complex widgets. It also meant that you were writing code in the presenter that was tied to the view's implementation. So 'em Google boy's made a simple by powerful amendment (http://code.google.com/webtoolkit/articles/mvp-architecture-2.html). A new interface "PresenterCallback" is something that the Presenter implements and offers to the view. This means that rather than coding all the Handlers/Listeners in the presenter (that are often typed against the View's implementing widgets*) , the view trigger's methods defined in the callback and implemented in the Presenter. What seemed to happened was that the presenter (in between Views) was often omitted because people could see the work involved. The "PrestenterCallback" is not only easier to work with, but much better in practice with complex widgets/html and is probably related to your "complex widget" concerns/questions. 

*side note...  why should you be coding (Button) click handlers in the Presenter? When you find out that the view would be better with keystroke or drag and drop you shouldn't be changing the presenter.

Best advice I can give is to be patient. Digesting MVP, Gin, Command Pattern, UiBinder... all at once is a very sharp + steep learning curve. Once you are past it, it will be much easier to see where the real complexity is :)

Wow, that took so much longer than I thought.

Ciao :)

p.s. the "passing" of the eventBus is normally a singleton you would @Inject with Gin. Services are probably injected the same way too.

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

[felipenasc]

You could take a look at gwt-platform ( http://code.google.com/p/gwt-platform/
), a complete GWT MVP Framework.
It does support a lot of features required by real applications (not
Helloworld ones).

Cheers
Felipenasc

[drthink]

Go for it. I would also appreciate it sooner than later.

On Jun 27, 9:35 am, felipenasc <felipen...@gmail.com> wrote:
> You could take a look at gwt-platform (http://code.google.com/p/gwt-platform/