Feedback on "Large scale app development MVP article"
28 views
Skip to first unread message
nogridbag
Jun 1, 2010, 1:38:00 PM6/1/10
to Google Web Toolkit
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!
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!
Sripathi Krishnan
Jun 1, 2010, 2:30:07 PM6/1/10
to google-we...@googlegroups.com
There are a few things that you should keep in mind before you try to understand the MVP pattern
- You don't have reflection or observer/observable pattern on the client side.
- 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.
--
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.
nogridbag
Jun 1, 2010, 3:38:09 PM6/1/10
to Google Web Toolkit
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 <sripathi.krish...@gmail.com>
wrote:
> side.
> 2. Views depend on DOM and GWT UI Libraries, and are difficult to
> have the RPC logic to initialize the model?*
>
> --Sri
> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsu...@googlegroups.com>
> > .
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 <sripathi.krish...@gmail.com>
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
> understand the MVP pattern
>
> 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?*
>
> Now, to answer some of your questions
>
> - 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
> 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.
>
> 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?*
> 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.
>
> 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?*
> 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.
>
> 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*
> 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.
>
> 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 <http://www.quirksmode.org/js/events_order.html>.
> optimization. For general concepts on the subject, you may want to read this
>
> --Sri
> > .
jocke eriksson
Jun 1, 2010, 5:00:09 PM6/1/10
to google-we...@googlegroups.com
Am I stupid or isn't EventBus an implementation of observer/observable.
2010/6/1 Sripathi Krishnan <sripathi...@gmail.com>
jocke eriksson
Jun 1, 2010, 5:04:41 PM6/1/10
to google-we...@googlegroups.com
I will answer my own question here, yes I am !! Thank god for the power of google.
2010/6/1 jocke eriksson <joc...@gmail.com>
Tristan
Jun 2, 2010, 1:08:53 PM6/2/10
to Google Web Toolkit
@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 <jock...@gmail.com> wrote:
> I will answer my own question here, yes I am !! Thank god for the power of
> google.
>
> 2010/6/1 jocke eriksson <jock...@gmail.com>
> >> client side.
> >> 2. Views depend on DOM and GWT UI Libraries, and are difficult to
> >> have the RPC logic to initialize the model?*
> >> model?*
>
> >> --Sri
> >>> google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
> >>> .
> >> .
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 <jock...@gmail.com> wrote:
> I will answer my own question here, yes I am !! Thank god for the power of
> google.
>
>
>
>
> > Am I stupid or isn't EventBus an implementation of observer/observable.
>
> > 2010/6/1 Sripathi Krishnan <sripathi.krish...@gmail.com>
>
>
> > Am I stupid or isn't EventBus an implementation of observer/observable.
>
>
> > 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
> > There are a few things that you should keep in mind before you try to
> >> understand the MVP pattern
>
> >> 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?*
>
> >> Now, to answer some of your questions
>
> >> - 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
> >> 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.
>
> >> 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?*
> >> 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.
>
> >> 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
> >> 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.
>
> >> 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*
> >> 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.
>
> >> 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 <http://www.quirksmode.org/js/events_order.html>.
> >> optimization. For general concepts on the subject, you may want to read this
>
> >> --Sri
> >>> .
> >>> 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-we...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
> >>>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-we...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> .
nogridbag
Jun 2, 2010, 2:43:01 PM6/2/10
to Google Web Toolkit
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.
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.
Tristan
Jun 2, 2010, 3:09:43 PM6/2/10
to Google Web Toolkit
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.
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.
Thomas Broyer
Jun 3, 2010, 10:26:30 AM6/3/10
to Google Web Toolkit
On 2 juin, 20:43, nogridbag <nogrid...@gmail.com> 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.
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.
Tristan Slominski
Jun 3, 2010, 11:15:10 AM6/3/10
to google-we...@googlegroups.com
i think at this point we should all probably see
and see what they're trying to do there. Seems like Google decided the MVP approach is obsolete, which might muddle the issue.
--
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.
Thomas Broyer
Jun 3, 2010, 11:53:56 AM6/3/10
to Google Web Toolkit
On 3 juin, 17:15, Tristan Slominski <tristan.slomin...@gmail.com>
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!
> and see what they're trying to do there. Seems like Google decided the MVP
> approach is obsolete, which might muddle the issue.
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 <t.bro...@gmail.com> wrote:
>
> > On 2 juin, 20:43, nogridbag <nogrid...@gmail.com> 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:
>
> > .
Tristan Slominski
Jun 3, 2010, 12:02:32 PM6/3/10
to google-we...@googlegroups.com
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.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
Duong BaTien
Jun 3, 2010, 3:23:33 PM6/3/10
to google-we...@googlegroups.com
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.
(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
> To post to this group, send email to google-web-
> too...@googlegroups.com.
> To unsubscribe from this group, send email to google-web-
> toolkit+u...@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-
> too...@googlegroups.com.
> To unsubscribe from this group, send email to google-web-toolkit
> +unsub...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages