I'm trying to figure out how to make this parallel composite views /
presenter hierarchies.
And in my opinion it just break the MVP pattern.
One of the goals you pursuit with MVP is to decouple the View object
from the logic
it contains (the presenter). Making the Presenter unaware of how the
The increased complexity is definitely an issue. I don't like the idea
of yet more interfaces to have to worry about. It's a shame that part
2 of the MVP article doesn't address testing beyond simply mentioning
that these practices improve testability. It would be much clearer to
see
I could comprehend part I after watching Ray's presentation and
reading it a few times... it gave me a much better idea on how to
structure my application, but part II things started to fall apart for
me. It was very difficult to keep track of the additional layers of
abstraction introduced and
Sorry Mike, but I don't understand what you mean.
Could you point me to the concrete lines of code which are not clear,
or send code to use the libraries in a better way?
Thanks
-Manolo
On Wed, May 5, 2010 at 4:11 PM, Mike m...@sheridan-net.us wrote:
Manolo,
I may be mistaken, but I wasn't
Manolo,
I may be mistaken, but I wasn't able to replicate what you'd done.
Taking either the released .jar files for gwt-dispatch and gwt-
presenter, or having gotten the latest code from the repository --
either way, there were differences between what you'd coded and what
the library was
I'm using the latest code of gwt-presenter from svn, so if you don't
use maven you should either compile gwt-presenter, or download the
library from:
Hello there,
IMHO, one of the issues of MVP and Gwt is the lack of good examples
showing how to use all the layers (including command pattern,
injection and event bus), how to test all the code, and how to
integrate the set of libraries available.
Taking the project Hupa as reference, I have
You can download the project and play with it:
svn checkouthttp://gwt-workshop.googlecode.com/svn/trunk/GwtWsMvpContacts
GwtWsMvpContacts
mvn clean test gwt:run package
Looks very interesting. I've downloaded the project and imported to
Eclipse (don't have Maven yet).
First question:
The
There is quite a serious collision between the MVP pattern and the (super
cool) UiBinder.
Presenters don't know what their concrete view is, all they know is the view
interface has a asWidget() method. This seems like a logical separation. MVP
says presenters shouldn't know HOW they are visually
Hi,
originally the MVP pattern was design for separating the view from its
logic and the model it is displaying (as the MVC). Since the arriving
of UIBinder I found the word View misused. Actually, strictly speaking
the View is contained in the ui.xml file and the Controller is the
corresponding
I agree that it would be very helpful to see some examples of building
a more complex composite UI.
I've been trying to find a good way to handle this while keeping a
clean separation between view and presenter. It gets worse when trying
to use GIN along with UiBinder. Both help with construction
I've read it and IMHO it suffers from extreme over-compexity. Problem
is people will take this article as a reference for their designs.
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to
On Apr 22, 9:27 am, interdev jason.ved...@gmail.com wrote:
Hello everyone,
have you seen the new MVP Architecture article from google
?http://code.google.com/webtoolkit/articles/mvp-architecture-2.html
First, I only read it quickly, I didn't download and looked at the
sample project.
they
On Apr 24, 2:04 am, Paul Stockley pstockl...@gmail.com wrote:
I like the model-view-presenter architecture. However I am not at all
sold on mocking out the view and testing just the presenter. The
problems is that you are not testing 3 of the potentially most error
prone parts of the system:
I like the model-view-presenter architecture. However I am not at all
sold on mocking out the view and testing just the presenter. The
problems is that you are not testing 3 of the potentially most error
prone parts of the system: 1) The browser and DOM, 2) The GWT widget
library and 3) the
On Thu, Apr 22, 2010 at 3:27 AM, interdev jason.ved...@gmail.com wrote:
Hello everyone,
have you seen the new MVP Architecture article from google ?
http://code.google.com/webtoolkit/articles/mvp-architecture-2.html
they have changed the structure slightly, instead of having a View and
a
Hello everyone,
have you seen the new MVP Architecture article from google ?
http://code.google.com/webtoolkit/articles/mvp-architecture-2.html
they have changed the structure slightly, instead of having a View and
a Presenter which has an inner Interface (Display), aside from the
UiBinder part,
I think it's a very good explanation on MVP. But one thing that comes to
mind is that they should explain why they check for nulls all the time. I
think the if statements should be followed by else, at lest empty ones!
explaining why it is ok to ignore the call.
ex.
if (presenter != null) {
I like the model-view-presenter architecture. However I am not at all
sold on mocking out the view and testing just the presenter. The
problems is that you are not testing 3 of the potentially most error
prone parts of the system: 1) The browser and DOM, 2) The GWT widget
library and 3) the GWT
I was a bit disappointing. The example project wasn't even fully re
factored. The edit contacts view and presenter still reflect the old
architecture.
I think that though these tutorials are helpful its been almost a
whole year since part I of the article was posted. Also for trying to
make
@Bryan,
We'll get around to refactoring the EditContact View/Presenter, but the goal
was to get the new View/Presenter relationship out there as soon as we
could. We think it's a pattern that has worked for internal teams, and we
hope that it works for the larger community as well.
Regarding the
21 matches
Mail list logo
