For my last work project, we used Kiyaa!, a GWT library that offers its own
declarative UI system (and data-binding). In addition, we used PureMVC as a
very lightweight MVC-framework. If you're familiar with PureMVC, you'll know
that it's much closer to MVP, as described by Ray Ryan, than it is a
traditional MVC framework. They worked beautifully together. Here's our
basic setup:
- *Views *- these are the plain UI components represented with Kyiaa!
templates. They're smart enough to display Model data and handle any UI
interactions, but delegate all business logic to their Mediators. They have
a Listener interface that is implemented by the Mediator, which has
"high-level" callback methods, such as onRegister, onNewCustomer, etc rather
than onClick.
- *Mediator *- responsible for "managing" the views by facilitating
communication between the View and the rest of the system. They send and
receive Notifications that are handled by other Mediators or by Commands.
More specifically, they provide model data to the View as it's available and
handle user-triggered events from the view, etc. The mediators have NO
references to any Widgets or other UI components. Their only interaction
with the View is from callbacks through the defined interface and through
the View's public API, which is generally fairly-high level as well. Because
of this, it's easy to re-use UI components by having a different Mediator
controlling the UI.
- *Model* - these are your basic domain objects. They should be POJOs and
have no concept of the rest of the system. Period.
- *Proxy* - a Proxy's basic role is to provide a high-level API for
managing the Model. Depending on the complexity of your domain object, it
could be as simple as having methods such as addUser, deleteUser, etc. Or,
for complex Models, such as a Word Document object, can have methods such as
setTitle(), etc.
In our setup, Proxys take the former role, basically encapsulating all RPC
logic, implementing client-side caching, etc. You call methods on a Proxy,
such as saveUser, and it sends Notifications to the rest of the system when
something interesting happens. Proxy's NEVER receive notifications, however.
They are not interested in the rest of the system, including the UI (or even
that there is a UI), and theoretically, along with the models, should
function completely on their own, making them highly reusable.
- *Command* - a Command is a place where you encode complex interactions.
For example, if your application has a search function, you may have a
SearchCommand that
1. Receives the search query
2. Calls the appropriate Proxy to do the RPC hit
3. Loads the Mediator that will be interested in the Proxy's response,
if not already loaded
The SearchCommand would be triggered by a notification sent from some
Mediator. The idea is to stick the logic into a re-usable Command rather
than encoding it into a Mediator directly, as it may be needed from multiple
places.
The great part about this design and MVP is, that if we want to switch to
UIBinder, all we have to do is modify the View classes. No other part of the
system would have to change one-bit.
Another quick note on PureMVC: it's kind of a disservice to it to call it an
MVC framework, as there's very little code involved in the "framework".
Rather, it's a set of concepts and principles that have been very well
defined, that if followed correctly, lead to highly-reusable and easily
testable components. Even if you don't use the framework, I highly recommend
reading their best practices:
http://puremvc.org/component/option,com_wrapper/Itemid,174/
- Amir
On Thu, Aug 13, 2009 at 2:27 AM, Andrés Testi <andres.a.te...@gmail.com>wrote:
>
> How the UiBinder fits in the MVP architecture proposed at the google I/
> O talks? (http://code.google.com/intl/es-AR/events/io/sessions/
> GoogleWebToolkitBestPractices.html)
> Regards.
>
> - Andrés
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
