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. On Fri, Jun 25, 2010 at 3:46 PM, drthink <[email protected]> wrote: > 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 > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-web-toolkit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
