Re: MVP and RPC: What makes sense?

2012-02-20 Thread Matias Costa
> why should the View tell the Presenter "get the file" and the Presenter 
the tell the 
> view "show this file".

Because :

1) Error handling, this complicates the logic.
2) Display independence. Useful if you go mobile or more usual, while you 
create a new version of the interface, you can have a stable version to 
ship updates.
3) Testability. It is easy to test blind logic. Good luck testing a view.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/cZUvmRZ6_rIJ.
To post to this group, send email to google-web-toolkit@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.



MVP and RPC: What makes sense?

2012-02-20 Thread Thad
I'm still trying to get my head around this aspect of MVP: Where do I
handle my RPC calls? Theory's answer seems to be "in the Activity/
Presenter" while simplicity's answer as often is "in the View". I'm
mindful of Thomas Broyer's comment, "My rule of thumb: do what you
think is best for you" (http://groups.google.com/group/google-web-
toolkit/msg/2b758d66dc1c13f0). The best answer to Activity/Presenter
vs. View seems to be "it depends".

Here's the situation that arises in my current application: Within a
View a user will open and edit a document. The document may be opened
from the server through a list of available documents, from the local
workstation though a FormPanel and FileUpload widget, or created new
within my app (which may involve an optional image that is also
selected via a FormPanel and FileUpload).

In the case of the listing the server documents, it makes sense to
Place to request the list as well as a Place that uniquely selects the
document on the server. In either case I would ask the Activity to
make the RPC call and the Activity/Presenter to tell the View "display
this".

However in the case of a local file, the user selects the file within
the View (the FileUpload) then clicks a submit button within the View
(the FormPanel) that uploads the file. The upload's
SubmitCompleteHandler triggers an RPC call to open the document from
the server for display in the browser. In this case, why should the
View tell the Presenter "get the file" and the Presenter the tell the
view "show this file". It seems to me that the steps from picking the
local file through its display can be handled entirely--and more
simply--within the View. Bringing the Presenter into it complicates
the code.

Another RPC that seems to belong solely with the View is one where the
View needs information for display that can be calculated only on the
server and that is not useful outside of the View. Examples might be
image DPI, image color depth, or processing text files where a String
returned from via RPC to the TextArea display might eat non-printing
characters. In this case, why should the View ask the Presenter and
the Presenter then update the View? Again, bringing the Presenter into
it complicates the code. (As for testing, the heavy lifting is done
server-side and the tests are performed on the server side.)

Finally, an example not involving RPC that seems go belong solely
within the View: Changing the state of one widget that enables/
disables or shows/hides other widgets. Yes, Presenters tell Viewers to
display, but in this case why make the trip back and forth? The app's
other Views don't care what is selected moment to moment, only what
final generated object is.

Thoughts? Comments?

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.