Skip to main content

Home/ GWT - MVP/ Group items tagged tutorial

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Esfand S

new GWT MVP article (part 2) - Google Web Toolkit | Google Groups - 0 views

groups.google.com/...85595701a5139299

gwt uibinder mvp mvc

shared by Esfand S on 13 May 10 - Cached
  • 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 java file which is implementing the corresponding logic and instanciation. This file merely represents a kind of Controller. The Presenter used in this tutorial is (for me) nothing more than a ControllerProvider which enable the ability to provide differents implementations of the view logic. What I'm founding strange is the fact that their are using the same acronym (MVP) for two differents approaches :  - first one was Presenter centered as the abstraction was done on Display and aggregation were done against the presenter  - second one was Display AND Presenter centered as the abstraction is done on Presenter and Display the both referencing each other. But this approach is mainly due to the fact that UIBinder is removing a lot of boiler plate code from event handling (and first MVP tutorial was not using it), but in the same way UIBinder tends people to adapt the original MVP pattern to be able to use all its power ! That why there is so much reflexion to mix UIBinder and MVP together.
Esfand S

concerns on 2.1 MVP approach - Google Web Toolkit | Google Groups - 1 views

groups.google.com/...ccca7085faa14fe1

mvp gwt gwt21 top

shared by Esfand S on 09 Jul 10 - Cached
  • I really do not approach the different features of 2.1 as a whole "MVP" set of things: there's  - RequestFactory and ValueStore (I don't think ValueStore has any real use besides RequestFactory, though I'd be happy to be proved wrong) for a record-oriented client-server communication;  - Cell-based widgets for efficient data-backed lists, trees and tables  - PlaceController as typed layer over History (objects rather than strings, even though it's not yet plumbed to History, which at least proves it can be used without it)  - ActivityManager as an "application controller" (to use the term from the GWT tutorials) on top of PlaceController  - and on top of that, GWT provides some base activities plumbed with RequestFactory  - and finally, though it's not documented at all, EditorSupport which works with UiBinder in a view to generate "data-binding code" (as far as I understood) You're free to use any of them independently of the others.
Esfand S

overlook - Tech Blog - 2 views

www.over-look.com/...t-2-1-tutorial-1-mvp-the-model

gwt gwt21 mvp

shared by Esfand S on 09 Jul 10 - Cached
  • The main issue in MVC is that these three elements are tighly bound together: the controller has to register to both the model and the view (and unregister if either changes), and when a view serves multiple controllers or a controller uses multiple models, that becomes quickly a mess.
  • MVP approach is more message-oriented. All messages (events) are fired on a single EventBus that is shared by all Presenters. Each presenter listens to events of interest, and fires new events according to actions. So a change in the in the EmployeeModel may be fired with an EmployeeModelChangedEvent, instead of attaching a listener to the model object. And we can easily create new Presenters that receive that same event and react accordingly.
  • The magnitude of such a shift is great: the model is no more the center and source of events (which would require special care in attaching and detaching to a specific instance), but it more a passive container of data, which may be copied, proxied, transformed, cached, without the GWT appliction any special care.Since the model is more a container of data ment for communication, I've highlighted the fact that it needs to be Serializable.
  • ...11 more annotations...
  • It is now the time to introduce the Model in GWT 2.1. The direction taken in 2.0.x has been pushed one step further, so that the Model is, in fact, only a Data Transfer Obejct (DTO). A DTO is an object whose main purpose is to be transferred, usually from one Tier to another Tier of a layered architecture such as Browser/Server/Database.
  • Value Store, the package that defines the Model/DTO programming interface.
  • Valuestore is the management interface that performs CRUD (Create, Read, Update, Delete) operations on the Records, like Entity Manager in JPA and Persistence Manager in JDO.
  • The first interface to discuss is Record, the base interface to implement to define a DTO class. A Record holds data for a single instance of an entity. Let's suppose that in your server-side business model there's an entity called 'Employee' to represent a company employee list.  To use it on the client side, you would need to define an EmployeeRecord class to hold the values of one of your employees, e.g. the employee name, birth date, etc.
  • A Record is able to provide values using Property objects as keys. The properties are type-aware, so that the employee name is a Property<String>, the employee birth data a Property<Date>, and so on. The following table reports these elements in a single example:
  • The Record interface doesn't provide a generic reflection mechanism, so it's not possible to inspect a Record to know what kind of Properties it is made of. The current implementation RecordImpl, which delegates to JavaScriptObject implementation and provides JSON serialization, is actually holding a schema of the record properties in a RecordSchema object.
  • note the annotation @DataTransferObject, that GWT uses to map the record to the equivalent server-side class. By declaring the connection, GWT is capable of binding automatically the interface properties with the JPA-annotated properties, thus greatly reducing the amount of boilerplate mapping work to be performed.
  • Of course, when you add or modify a property in your real Model, appropriate changes must be applied to the equivalent Record. That's where the teamwork with Spring Roo comes handy: Spring Roo generates and keeps aligned a lot of these elements, and would reflect (overwrite) your EmployeeRecord java file every time you change your domain model definition.
  • As a general rule, you are encouraged to define specific interface methods to extract data from you Record, e.g. getName() to get the Employee name. Record exposes also method to retrieve a value given a property. For instance, in a Renderer of a CellTree, when you are given an EmployeeRecord you should access its data through public getter methods.
  • The model-agnostic way that GWT uses to access a value is the Record.get(Property<V>) method. There's also a way to get not the value itself, but a PropertyReference<V>, which is just the property of a specific record, e.g. the Property 'name' of Record 'r2' in the example table above. In a few words, a property reference is just a value, which is exactly how Value<V> is defined. That is most useful to perform late bindings during RPC calls when the data is not yet available.
  • The DeltaValueStore is also worth mentioning a few words: as your model is now decomposed in Records and Properties, it is also possible to transfer only the data you need to. Hence the retrieval requests can dowload only a few properties of the Records. Furthermore, 'Update' operations can transmit back only the user changes (delta) instead of whole objects, which may give a nice performance boost.
Marco Antonio Almeida

gwt-platform - Project Hosting on Google Code - 0 views

code.google.com/gwt-platform

gwt framework opensource java web programming tutorial guice ioc mvp

shared by Marco Antonio Almeida on 24 Oct 10 - Cached
  • Moreover, GWTP strives to use the event bus in a clear and efficient way. Events are used to decouple loosely related objects, while direct method invocation is used to clarify the program flow between strongly coupled components. The result is an application that is easy to understand and that can grow with time.
  • Marco Antonio Almeida on 24 Oct 10
     
    "GIN and Guice"
1 - 16 of 16
Showing 20▼ items per page