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

[Duong BaTien]

I also like to see 
  (1) how existing MVP frameworks such as GWTP, handlebars, etc response
to the new proposal of DTO, View, Activities and ActivityManager to
EventBus. Comments from developers of the MVP frameworks would be very
helpful.
  (2) how to leverage ROO generated codes for JSONP Cross Site Requests
with REST services and other GAE persistent technologies.

  (3) DAO <-> DTO and EventBus at server side of GAE 

Thanks

Duong BaTien
DBGROUPS and BudhNet

On Thu, 2010-06-03 at 10:15 -0500, Tristan Slominski wrote:
> i think at this point we should all probably see
> 
> 
> http://code.google.com/events/io/2010/sessions/architecting-
> production-gwt.html
> 
> 
> and see what they're trying to do there. Seems like Google decided the
> MVP approach is obsolete, which might muddle the issue.
> 
> On Thu, Jun 3, 2010 at 09:26, Thomas Broyer 
> wrote:
> 
> 
> On 2 juin, 20:43, nogridbag  wrote:
> > Mainly because of habit - I always try to avoid mixing UI
> related code
> > with client/server code.  IMHO, it seems similar to doing
> RPC calls in
> > a controller or view in MVC which I think is a big no-no.
> >
> > Sticking with the article example, let's say you have two
> places where
> > you want to display contacts.  The data is the same, but the
> views may
> > be completely different and thus you may want different
> presenters.
> >
> > So now you have:
> > ContactsModel
> > ContactsPresenter
> > ContactsView
> >
> > ContactsPresenter2
> > ContactsView2
> >
> > You already have the RPC call to load and initialize the
> ContactsModel
> > in ContactsPresenter. Do you simply duplicate this in
> > ContactsPresenter2 or does ContactsPresenter2 have a
> dependency on
> > ContactsPresenter?
> >
> > Anyway, I'm really just thinking out loud here ;)  I haven't
> sat down
> > and coded any thing with MVP yet.  If this is the accepted
> practice I
> > will probably do it this way too.
> 
> 
> How about using some client-side cache, so that when your
> second
> presenter asks for the same data as the first one, you don't
> send a
> request on the wire (have a look at Ray Ryan's I/O 2009 talk:
> 
> http://code.google.com/events/io/2009/sessions/GoogleWebToolkitBestPractices.html
> )
> Your presenters don't have to know there's some caching
> involved
> though, as long as the service instance is injected into the
> presenter, you can pass a "right to the wire" implementation
> (a direct
> GWT.create() on your service interface) or a "through cache"
> implementation.
> 
> If you want your views to be somehow "synchronized" (when one
> presenter makes a request, the other is informed, at least
> when the
> response comes back), then fire some events on the event bus
> (again,
> this would be implemented in your service, not in the
> presenters
> themselves).
> 
> Again, MVP as used in GWT (at least as promoted by Google) has
> mainly
> three goals:
>  - making unit tests possible in "pure Java" (no browser, or
> browser-
> emulation, involved), which reduces testing time drastically!
>  - decoupling things a bit so you could use different views
> for a
> single "presentation logic" (let's say a desktop view that
> presents
> data in columns, and a mobile view that uses a taller single-
> column
> screen)
>  - presenters a lightweight compared to views, so instead of
> "resetting" your presenter with some new data, just throw it
> away,
> create a new one with the new data, and "attach" it to the
> very same
> view.
> 
> 
> --
> 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-
> tool...@googlegroups.com.
> To unsubscribe from this group, send email to google-web-
> toolkit+unsubscr...@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-
> tool...@googlegroups.com.
> To unsubscribe from this group, send email to google-web-toolkit
> +unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/g

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

[Tristan Slominski]

maybe it's that I expect too much MVPness from an MVP framework? as you
pointed out, the data widgets are pretty much the MVC observer pattern that
uses Request Factory to get it's stuff. From the programmer's perspective i
would argue that a data widget has nothing to do with MVP (not as i look at
it as a programmer and how it fits as a component into my application). it's
not a bad thing in itself, but when I'm writing a large application, then
this is where complexity begins...  now I have some MVP things, ok, let's
add some data widgets that talk directly to things.. ok, let's tie my data
directly to JPA representation on the server... and viola, I have a
datastore viewer in GWT. Sort of missing the point of a rich web application
I think.

On Thu, Jun 3, 2010 at 10:53, Thomas Broyer  wrote:

>
>
> On 3 juin, 17:15, Tristan Slominski 
> wrote:
> > i think at this point we should all probably see
> >
> > http://code.google.com/events/io/2010/sessions/architecting-productio...
> >
> > and see what they're trying to do there. Seems like Google decided the
> MVP
> > approach is obsolete, which might muddle the issue.
>
> Not at all, on the contrary!
> It however clarify things about how Google sees MVP in GWT.
> They're even adding some MVP "framework" to GWT 2.1 (IsWidget and
> Activities, where an Activity is more or less your presenter, from
> what I understood).
> RequestFactory on the other hand is a new thing for efficient CRUD
> operations on entity objects, which plugs more-or-less directly into
> the new Data widgets. Those widgets do blur the line a bit, but
> they're not really about presentation "logic", and they're somehow MVP-
> based themselves.
>
> >
> >
> >
> > On Thu, Jun 3, 2010 at 09:26, Thomas Broyer  wrote:
> >
> > > On 2 juin, 20:43, nogridbag  wrote:
> > > > Mainly because of habit - I always try to avoid mixing UI related
> code
> > > > with client/server code.  IMHO, it seems similar to doing RPC calls
> in
> > > > a controller or view in MVC which I think is a big no-no.
> >
> > > > Sticking with the article example, let's say you have two places
> where
> > > > you want to display contacts.  The data is the same, but the views
> may
> > > > be completely different and thus you may want different presenters.
> >
> > > > So now you have:
> > > > ContactsModel
> > > > ContactsPresenter
> > > > ContactsView
> >
> > > > ContactsPresenter2
> > > > ContactsView2
> >
> > > > You already have the RPC call to load and initialize the
> ContactsModel
> > > > in ContactsPresenter. Do you simply duplicate this in
> > > > ContactsPresenter2 or does ContactsPresenter2 have a dependency on
> > > > ContactsPresenter?
> >
> > > > Anyway, I'm really just thinking out loud here ;)  I haven't sat down
> > > > and coded any thing with MVP yet.  If this is the accepted practice I
> > > > will probably do it this way too.
> >
> > > How about using some client-side cache, so that when your second
> > > presenter asks for the same data as the first one, you don't send a
> > > request on the wire (have a look at Ray Ryan's I/O 2009 talk:
> >
> > >http://code.google.com/events/io/2009/sessions/GoogleWebToolkitBestPr.
> ..
> > > )
> > > Your presenters don't have to know there's some caching involved
> > > though, as long as the service instance is injected into the
> > > presenter, you can pass a "right to the wire" implementation (a direct
> > > GWT.create() on your service interface) or a "through cache"
> > > implementation.
> >
> > > If you want your views to be somehow "synchronized" (when one
> > > presenter makes a request, the other is informed, at least when the
> > > response comes back), then fire some events on the event bus (again,
> > > this would be implemented in your service, not in the presenters
> > > themselves).
> >
> > > Again, MVP as used in GWT (at least as promoted by Google) has mainly
> > > three goals:
> > >  - making unit tests possible in "pure Java" (no browser, or browser-
> > > emulation, involved), which reduces testing time drastically!
> > >  - decoupling things a bit so you could use different views for a
> > > single "presentation logic" (let's say a desktop view that presents
> > > data in columns, and a mobile view that uses a taller single-column
> > > screen)
> > >  - presenters a lightweight compared to views, so instead of
> > > "resetting" your presenter with some new data, just throw it away,
> > > create a new one with the new data, and "attach" it to the very same
> > > view.
> >
> > > --
> > > 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-tool...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > google-web-toolkit+unsubscr...@googlegroups.com cr...@googlegroups.com>
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/google-web-toolkit?hl=en.
>
> --
> You received this message bec

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

[Thomas Broyer]

On 3 juin, 17:15, Tristan Slominski 
wrote:
> i think at this point we should all probably see
>
> http://code.google.com/events/io/2010/sessions/architecting-productio...
>
> and see what they're trying to do there. Seems like Google decided the MVP
> approach is obsolete, which might muddle the issue.

Not at all, on the contrary!
It however clarify things about how Google sees MVP in GWT.
They're even adding some MVP "framework" to GWT 2.1 (IsWidget and
Activities, where an Activity is more or less your presenter, from
what I understood).
RequestFactory on the other hand is a new thing for efficient CRUD
operations on entity objects, which plugs more-or-less directly into
the new Data widgets. Those widgets do blur the line a bit, but
they're not really about presentation "logic", and they're somehow MVP-
based themselves.

>
>
>
> On Thu, Jun 3, 2010 at 09:26, Thomas Broyer  wrote:
>
> > On 2 juin, 20:43, nogridbag  wrote:
> > > Mainly because of habit - I always try to avoid mixing UI related code
> > > with client/server code.  IMHO, it seems similar to doing RPC calls in
> > > a controller or view in MVC which I think is a big no-no.
>
> > > Sticking with the article example, let's say you have two places where
> > > you want to display contacts.  The data is the same, but the views may
> > > be completely different and thus you may want different presenters.
>
> > > So now you have:
> > > ContactsModel
> > > ContactsPresenter
> > > ContactsView
>
> > > ContactsPresenter2
> > > ContactsView2
>
> > > You already have the RPC call to load and initialize the ContactsModel
> > > in ContactsPresenter. Do you simply duplicate this in
> > > ContactsPresenter2 or does ContactsPresenter2 have a dependency on
> > > ContactsPresenter?
>
> > > Anyway, I'm really just thinking out loud here ;)  I haven't sat down
> > > and coded any thing with MVP yet.  If this is the accepted practice I
> > > will probably do it this way too.
>
> > How about using some client-side cache, so that when your second
> > presenter asks for the same data as the first one, you don't send a
> > request on the wire (have a look at Ray Ryan's I/O 2009 talk:
>
> >http://code.google.com/events/io/2009/sessions/GoogleWebToolkitBestPr...
> > )
> > Your presenters don't have to know there's some caching involved
> > though, as long as the service instance is injected into the
> > presenter, you can pass a "right to the wire" implementation (a direct
> > GWT.create() on your service interface) or a "through cache"
> > implementation.
>
> > If you want your views to be somehow "synchronized" (when one
> > presenter makes a request, the other is informed, at least when the
> > response comes back), then fire some events on the event bus (again,
> > this would be implemented in your service, not in the presenters
> > themselves).
>
> > Again, MVP as used in GWT (at least as promoted by Google) has mainly
> > three goals:
> >  - making unit tests possible in "pure Java" (no browser, or browser-
> > emulation, involved), which reduces testing time drastically!
> >  - decoupling things a bit so you could use different views for a
> > single "presentation logic" (let's say a desktop view that presents
> > data in columns, and a mobile view that uses a taller single-column
> > screen)
> >  - presenters a lightweight compared to views, so instead of
> > "resetting" your presenter with some new data, just throw it away,
> > create a new one with the new data, and "attach" it to the very same
> > view.
>
> > --
> > 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-tool...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-web-toolkit+unsubscr...@googlegroups.com > cr...@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-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

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

[Tristan Slominski]

i think at this point we should all probably see

http://code.google.com/events/io/2010/sessions/architecting-production-gwt.html

and see what they're trying to do there. Seems like Google decided the MVP
approach is obsolete, which might muddle the issue.

On Thu, Jun 3, 2010 at 09:26, Thomas Broyer  wrote:

>
>
> On 2 juin, 20:43, nogridbag  wrote:
> > Mainly because of habit - I always try to avoid mixing UI related code
> > with client/server code.  IMHO, it seems similar to doing RPC calls in
> > a controller or view in MVC which I think is a big no-no.
> >
> > Sticking with the article example, let's say you have two places where
> > you want to display contacts.  The data is the same, but the views may
> > be completely different and thus you may want different presenters.
> >
> > So now you have:
> > ContactsModel
> > ContactsPresenter
> > ContactsView
> >
> > ContactsPresenter2
> > ContactsView2
> >
> > You already have the RPC call to load and initialize the ContactsModel
> > in ContactsPresenter. Do you simply duplicate this in
> > ContactsPresenter2 or does ContactsPresenter2 have a dependency on
> > ContactsPresenter?
> >
> > Anyway, I'm really just thinking out loud here ;)  I haven't sat down
> > and coded any thing with MVP yet.  If this is the accepted practice I
> > will probably do it this way too.
>
> How about using some client-side cache, so that when your second
> presenter asks for the same data as the first one, you don't send a
> request on the wire (have a look at Ray Ryan's I/O 2009 talk:
>
> http://code.google.com/events/io/2009/sessions/GoogleWebToolkitBestPractices.html
> )
> Your presenters don't have to know there's some caching involved
> though, as long as the service instance is injected into the
> presenter, you can pass a "right to the wire" implementation (a direct
> GWT.create() on your service interface) or a "through cache"
> implementation.
>
> If you want your views to be somehow "synchronized" (when one
> presenter makes a request, the other is informed, at least when the
> response comes back), then fire some events on the event bus (again,
> this would be implemented in your service, not in the presenters
> themselves).
>
> Again, MVP as used in GWT (at least as promoted by Google) has mainly
> three goals:
>  - making unit tests possible in "pure Java" (no browser, or browser-
> emulation, involved), which reduces testing time drastically!
>  - decoupling things a bit so you could use different views for a
> single "presentation logic" (let's say a desktop view that presents
> data in columns, and a mobile view that uses a taller single-column
> screen)
>  - presenters a lightweight compared to views, so instead of
> "resetting" your presenter with some new data, just throw it away,
> create a new one with the new data, and "attach" it to the very same
> view.
>
> --
> 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-tool...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@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-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

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

[Thomas Broyer]

On 2 juin, 20:43, nogridbag  wrote:
> Mainly because of habit - I always try to avoid mixing UI related code
> with client/server code.  IMHO, it seems similar to doing RPC calls in
> a controller or view in MVC which I think is a big no-no.
>
> Sticking with the article example, let's say you have two places where
> you want to display contacts.  The data is the same, but the views may
> be completely different and thus you may want different presenters.
>
> So now you have:
> ContactsModel
> ContactsPresenter
> ContactsView
>
> ContactsPresenter2
> ContactsView2
>
> You already have the RPC call to load and initialize the ContactsModel
> in ContactsPresenter. Do you simply duplicate this in
> ContactsPresenter2 or does ContactsPresenter2 have a dependency on
> ContactsPresenter?
>
> Anyway, I'm really just thinking out loud here ;)  I haven't sat down
> and coded any thing with MVP yet.  If this is the accepted practice I
> will probably do it this way too.

How about using some client-side cache, so that when your second
presenter asks for the same data as the first one, you don't send a
request on the wire (have a look at Ray Ryan's I/O 2009 talk:
http://code.google.com/events/io/2009/sessions/GoogleWebToolkitBestPractices.html
)
Your presenters don't have to know there's some caching involved
though, as long as the service instance is injected into the
presenter, you can pass a "right to the wire" implementation (a direct
GWT.create() on your service interface) or a "through cache"
implementation.

If you want your views to be somehow "synchronized" (when one
presenter makes a request, the other is informed, at least when the
response comes back), then fire some events on the event bus (again,
this would be implemented in your service, not in the presenters
themselves).

Again, MVP as used in GWT (at least as promoted by Google) has mainly
three goals:
 - making unit tests possible in "pure Java" (no browser, or browser-
emulation, involved), which reduces testing time drastically!
 - decoupling things a bit so you could use different views for a
single "presentation logic" (let's say a desktop view that presents
data in columns, and a mobile view that uses a taller single-column
screen)
 - presenters a lightweight compared to views, so instead of
"resetting" your presenter with some new data, just throw it away,
create a new one with the new data, and "attach" it to the very same
view.

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

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

[Tristan]

I don't like having two presenters either. I'm not quite sure that's
what's required. My presenters have an adapter parameter, so one
presenter can be coupled with different views depending on what
adapter is selected. Then, depending if it's a listAdapter,
editAdapter, displayAdapter, the same DTO is given to the appropriate
view to display itself.

The big benefits of presenter design really revolve around fast tests.
That was clearly a design choice. On the other hand, if you take a
look at the new Roo and GWT 2.1 integration, I think the waters get
muddled as I *think* they advertise not needing all the layering and
the approach not being a pure MVP from what I understand. So it
doesn't seem like a hard fast rule, but I've found the pattern very
useful and it greatly simplified my development. There is only one
method that does important things in my presenter (not taking into
account refactoring methods out of course). So if logic breaks, I know
where it is and I have fast unit tests for it. Everything else is
declarative boiler plate.

On Jun 2, 1:43 pm, nogridbag  wrote:
> Mainly because of habit - I always try to avoid mixing UI related code
> with client/server code.  IMHO, it seems similar to doing RPC calls in
> a controller or view in MVC which I think is a big no-no.
>
> Sticking with the article example, let's say you have two places where
> you want to display contacts.  The data is the same, but the views may
> be completely different and thus you may want different presenters.
>
> So now you have:
> ContactsModel
> ContactsPresenter
> ContactsView
>
> ContactsPresenter2
> ContactsView2
>
> You already have the RPC call to load and initialize the ContactsModel
> in ContactsPresenter. Do you simply duplicate this in
> ContactsPresenter2 or does ContactsPresenter2 have a dependency on
> ContactsPresenter?
>
> Anyway, I'm really just thinking out loud here ;)  I haven't sat down
> and coded any thing with MVP yet.  If this is the accepted practice I
> will probably do it this way too.
>
> On Jun 2, 1:08 pm, Tristan  wrote:
>
>
>
> > @nogridbag
>
> > What are your reasons for not having the presenter make RPC requests?
> > The RPC Service is not a presenter itself. Probably the MVP model
> > should be called MVPSE (services, event bus) because that's what it
> > takes to make it really work.
>
> > On Jun 1, 4:04 pm, jocke eriksson  wrote:
>
> > > I will answer my own question here, yes I am !! Thank god for the power of
> > > google.
>
> > > 2010/6/1 jocke eriksson 
>
> > > > Am I stupid or isn't EventBus an implementation of observer/observable.
>
> > > > 2010/6/1 Sripathi Krishnan 
>
> > > > 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 vali

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

[nogridbag]

Mainly because of habit - I always try to avoid mixing UI related code
with client/server code.  IMHO, it seems similar to doing RPC calls in
a controller or view in MVC which I think is a big no-no.

Sticking with the article example, let's say you have two places where
you want to display contacts.  The data is the same, but the views may
be completely different and thus you may want different presenters.

So now you have:
ContactsModel
ContactsPresenter
ContactsView

ContactsPresenter2
ContactsView2

You already have the RPC call to load and initialize the ContactsModel
in ContactsPresenter. Do you simply duplicate this in
ContactsPresenter2 or does ContactsPresenter2 have a dependency on
ContactsPresenter?

Anyway, I'm really just thinking out loud here ;)  I haven't sat down
and coded any thing with MVP yet.  If this is the accepted practice I
will probably do it this way too.


On Jun 2, 1:08 pm, Tristan  wrote:
> @nogridbag
>
> What are your reasons for not having the presenter make RPC requests?
> The RPC Service is not a presenter itself. Probably the MVP model
> should be called MVPSE (services, event bus) because that's what it
> takes to make it really work.
>
> On Jun 1, 4:04 pm, jocke eriksson  wrote:
>
> > I will answer my own question here, yes I am !! Thank god for the power of
> > google.
>
> > 2010/6/1 jocke eriksson 
>
> > > Am I stupid or isn't EventBus an implementation of observer/observable.
>
> > > 2010/6/1 Sripathi Krishnan 
>
> > > 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  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

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

[Tristan]

@nogridbag

What are your reasons for not having the presenter make RPC requests?
The RPC Service is not a presenter itself. Probably the MVP model
should be called MVPSE (services, event bus) because that's what it
takes to make it really work.

On Jun 1, 4:04 pm, jocke eriksson  wrote:
> I will answer my own question here, yes I am !! Thank god for the power of
> google.
>
> 2010/6/1 jocke eriksson 
>
>
>
> > Am I stupid or isn't EventBus an implementation of observer/observable.
>
> > 2010/6/1 Sripathi Krishnan 
>
> > 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  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 vie

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

[jocke eriksson]

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

2010/6/1 jocke eriksson 

> Am I stupid or isn't EventBus an implementation of observer/observable.
>
> 2010/6/1 Sripathi Krishnan 
>
> 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  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 littl

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

[jocke eriksson]

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

2010/6/1 Sripathi Krishnan 

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

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

[nogridbag]

Thanks for your feedback Sri.

1 and 2.
In my opinion, the shared object would be DTO's - not models.  I don't
think they have to be the same.  You can have centralized RPC, but
somewhere the request is made - I don't think the RPC requests should
be done in presenter unless there will only ever be one presenter for
this model.

4. "Because then your views are no longer dumb."
In this case, I would rather create a read-only immutable version of
the model instead of adding an extra layer of abstraction with
generics.  Of course the down side to this (or abstracting it with
ColumnDefinition) is that more JS code is generated.  When you have an
app as large as ours, this really becomes an issue.

On Jun 1, 2:30 pm, Sripathi Krishnan 
wrote:
> 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  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 logi

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

[Sripathi Krishnan]

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

Feedback on "Large scale app development MVP article"

[nogridbag]

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