Re: Feedback on "Large scale app development MVP article"

I will answer my own question here, yes I am !! Thank god for the power of google.

2010/6/1 jocke eriksson <jocke29@gmail.com>

Am I stupid or isn't EventBus an implementation of observer/observable.

2010/6/1 Sripathi Krishnan <sripathi.krishnan@gmail.com>

There are a few things that you should keep in mind before you try to understand the MVP pattern

1. You don't have reflection or observer/observable pattern on the client side. 
2. Views depend on DOM and GWT UI Libraries, and are difficult to mock/emulate in a pure java test case

Now, to answer some of your questions 

1. Why should model just be POJO's?

- Models are shared by the server and client. If models contain code to make RPC calls, it won't work on the server side.

- Say the models make RPC calls and update themselves. How will the views know about this? Remember, there is no observer/observable pattern on the UI. 

- The only way multiple views can stay in sync is by listening to events. And events carry the model objects around, so everybody stays in sync.

2. You would have multiple presenters and one of them would arbitrarily have the RPC logic to initialize the model?

Have a central, command style RPC mechanism. When the data comes from the server, you put it on the event bus so that every view gets the updated data. If there is an error, you have a plug to do central error handling. You can also cache results centrally instead of hitting the server every time. 

3. Multiple views for the same model?

Its actually a very common thing. Say your model is a list of contacts. In gmail, the chat view needs this model. Also, the compose email view needs it to auto-complete the addresses. These views cannot "observe" the list fof contacts, so the only way for them to stay in sync is via events.

4. Why is it a poor design decision to let the view know about this model?

Because then your views are no longer dumb. And if they are not dumb, you'd have to test them, which we know is difficult to do via java.

If the view knows about the model, you will also be tempted to "read from the text box and populate the model". At some point, you would be tempted to add the validation in the view. And then there will be error handling. And slowly and surely, you have reached a stage where you cannot test your app easily. 

Which is why you want the view to only listen to low level browser events like clicks and key events, and then convert them to your apps vocabulary and then call the Presenter. Since Presenter is the only one which has any real code, and since it does not depend on the DOM, you can test them using only JUnit.

5. Event Handling

That part doesn't have to do with MVP, its purely a performance optimization. For general concepts on the subject, you may want to read this quirks mode article.

--Sri

On 1 June 2010 23:08, nogridbag <nogridbag@gmail.com> wrote:

Hi, I've been reading the articles on MVP recently, specifically the
articles here:

http://code.google.com/webtoolkit/articles/mvp-architecture.html
http://code.google.com/webtoolkit/articles/mvp-architecture-2.html

I've primarily worked with MVC in the past so this is my first
exposure to MVP (I've of course heard about it before but never really
cared to learn about it in depth).

Here's a few things that I wanted to comment on to perhaps help me
understand this all better.

1.  Everyone does MVC slightly differently, but I've always treated
the model as more than a simple data object.  In MVC, I've always
designed it so that it's the model's responsibility to do RPC calls -
not the controller.

In MVP, I noticed you suggest to put this logic in the presenter.  It
seems a little strange to me.  What if you want multiple views to
essentially be an observer of the same model (I know I'm speaking in
MVC terms but you get the idea).  You would have multiple presenters
and one of them would arbitrarily have the RPC logic to initialize the
model?  I know in practice there's very few times in which you
actually need to have multiple views for the same model - so I'm OK
with this decision.  Just an observation...

2. If the model is simply a DTO as you suggest, why is it a poor
design decision to let the view know about this model?  DTO's are
simple POJOs with no logic.  True, the view will become arguably a
little smarter.  But from a maintainability standpoint I don't see why
simply moving this to a third party class, ColumnDefinition, would
make it easier to maintain.  Whenever more abstraction is added, the
code is typically much more complicated, difficult to read and
understand the flow, etc.  When I look at that ContactsViewImpl with
all the generics everywhere, I cringe a little bit.  Honestly, I don't
have much experience with unit testing UI.  So maybe in a few
sentences can you explain why having the view have a dependency on the
model (a simple pojo) will make testing more difficult?

3.  My final comment is about sinking the events.  The article states:

"Reduce the event overhead by sinking events on the HTML widget,
rather than the individual cells."

In the code, I was expecting to see a single DOM.sinkEvents... but
instead it looks like each individual cell sinks events:

for row
 for col
      // TODO: Really total hack! There's gotta be a better way...
       Element child = cell.getFirstChildElement();
       if (child != null) {
         Event.sinkEvents(child, Event.ONFOCUS | Event.ONBLUR);
       }

Is this a mistake?  Or by "sinking events on the widget" you mean
sinking several events on a single widget is better than sinking
events on several widgets?

Thanks!

--
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-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
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 google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
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 google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.