[gwt-contrib] Re: UiBinder and Model View Presenter
Brett, We did code splitting across the four major sections of our applications. Assume we have section A-D, each with their own mediator. We then have an ApplicationMediator, which is responsible for loading / unloading the four major sections and sticking them into the viewport. When ApplicationMediator receives a notification to load A, for example, it calls a method loadA() that constructs the AMediator, gets its view component, and sticks it in the viewport. The trick is that loadA() is wrapped in a runAsyc() block and nowhere else do we ever construct an AMediator or even reference it, since communication is all through notifications. You could certainly do the same thing with a LoadACommand(). We just felt that since the command would have to work intimately with ApplicationMediator, it's best to just stick the logic in there. Our history management is pretty intense as our app is quite large and requires maintaining quite a bit of state (searches with up to 20-30 criteria). But, we did basically what you suggested. A HistoryManger class is responsible for serializing and deserializing history state. The rest of the application registers a certain token (say, search), providing a serializer and a Command. When it a history event is fired for that token, the entire state is serialized using the provided serializer then passed as an argument to the command. This works really well, because if you have a PerformSearch command that takes a SearchRequest as the body, it can be used for the history mechanism AND through normal user actions. The only bit about this I don't like, is that we use the third type parameter to signify whether the command is being called as a result of a user action or a history state change. If it's a user action, the command calls HistoryManager, allowing it to do it's History.addToken call. It's a bit hackish, but works. Hope that makes sense. - Amir On Wed, Aug 19, 2009 at 9:43 PM, brett.wooldridge brett.wooldri...@gmail.com wrote: Amir, After your post, I have been investigating PureMVC a bit. Since you used it, I have a question. In PureMVC, in the typical ApplicationFacade class there is an initializeController() override which registers all the commands. How does this fit with code- splitting? Currently our application is not PureMVC, and we highly leverage the new code-splitting features of GWT. Do you leverage code- splitting? If so, did you just register all the commands up front, but then in the execute() of the commands use runAsync() to allow splitting? Where are the best points to apply runAsync() in the PureMVC architecture? Also, while I have your attention, how did you (or did you) fit browser history into the PureMVC model? Did some sort of history management class receive notifications from the framework and manage history that way? Did that class post notifications into the PureMVC framework in response to back/forward navigation? Thanks. On Aug 14, 6:36 am, Amir Kashani amirkash...@gmail.com wrote: 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
[gwt-contrib] Re: UiBinder and Model View Presenter
Amir, After your post, I have been investigating PureMVC a bit. Since you used it, I have a question. In PureMVC, in the typical ApplicationFacade class there is an initializeController() override which registers all the commands. How does this fit with code- splitting? Currently our application is not PureMVC, and we highly leverage the new code-splitting features of GWT. Do you leverage code- splitting? If so, did you just register all the commands up front, but then in the execute() of the commands use runAsync() to allow splitting? Where are the best points to apply runAsync() in the PureMVC architecture? Also, while I have your attention, how did you (or did you) fit browser history into the PureMVC model? Did some sort of history management class receive notifications from the framework and manage history that way? Did that class post notifications into the PureMVC framework in response to back/forward navigation? Thanks. On Aug 14, 6:36 am, Amir Kashani amirkash...@gmail.com wrote: 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.comwrote: How the UiBinder fits in the MVP architecture proposed at the google I/ O talks?
[gwt-contrib] Re: UiBinder and Model View Presenter
Amir: Your answer is very interesting and detailed. Thank you very much for taking your time to answer my question. I will take a look in PureMVC. One of my big concerns is the translation of JSR 303 validations to client side. Regards. - Andrés On 13 ago, 18:36, Amir Kashani amirkash...@gmail.com wrote: 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.comwrote: 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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder and Model View Presenter
I don't want to speak for Ray here, since he gave the presentation, but my view is that they're largely orthogonal. UiBinder makes it easier to create views, but it has nothing in particular to say about how those views get bound to data. Its main goal is to remove the pain of UI construction, and to make it easier to mix widgets and HTML, hopefully leading to easier *and* more efficient UIs. From what I can see, there are a lot of approaches being explored by different teams for MVP, data binding, and other high-level architectures. I hope they will all mesh nicely with UiBinder. On Thu, Aug 13, 2009 at 5:27 AM, Andrés Testi andres.a.te...@gmail.comwrote: 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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder and Model View Presenter
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.comwrote: 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 -~--~~~~--~~--~--~---
