Understanding MVP
Hi everybody. I have a doubt about MVP approach in the Expenses app. In the ExpensesFactory, the main components of the ExpensesShell (ExpensesTree, ExpensesReportList and ExpensesReportDetails) are created. They get the requestFactory instance in their constructor in order to communicate with the model. The thing is that ExpensesTree is only a Composite, I mean, it is not an activity but it actually talks to the server via the requestFactory instance. And this is what confuses me. It´s a View talking directly to the model without taking into account a Presenter (Activity). Is this correct? Am I wrong? Thank you very much. -- 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.
Re: Understanding MVP
In other words, the ExpensesTree component does not use MVP. It's a choice made by the developer. No-one and nothing force you to split your components into a view and a presenter. -- 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.
Re: Understanding MVP
Of course no-one and nothing forces me to use MVP pattern, but that´s the way. I mean, it´s a kind of coding philosophy. The MVP pattern is supposed to be followed in the whole application... right? Now, I´m a bit more confused... what´s the way the application has to behave? MVP here and there? MVP here but not there? Sorry for my confusion but, again, Thomas I need an expert opinion. Thank you very much. -- 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.
Re: Understanding MVP
On Friday, February 11, 2011 5:00:37 PM UTC+1, ernesto.reig wrote: Of course no-one and nothing forces me to use MVP pattern, but that´s the way. I mean, it´s a kind of coding philosophy. The MVP pattern is supposed to be followed in the whole application... right? Well... no. There are times when you might consider that MVP is not worth it (in this case, ExpensesTree was –I guess– judged so simple that it didn't require unit-testing the presentation logic, hence no *need* to decouple a presenter from the view; they traded testability for simplicity). Now, I´m a bit more confused... what´s the way the application has to behave? MVP here and there? MVP here but not there? Why not? But if you're uncomfortable with it, then simply go with MVP everywhere (the Expenses sample is very simple, so it's not an issue not to have a single way of doing things; it can become one with a bigger app though, as it's easier to understand things if they're all made on the same basis). Sorry for my confusion but, again, Thomas I need an expert opinion. If you want my opinion: stick with a single rule (i.e. MVP everywhere), unless it's very impractical (and then document why you broke the rule). My point was that you shouldn't be confused if everyone is not following a single rule for the whole project. -- 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.
