Skip to main content

Home/ Groups/ GWT - MVP
Rss Feed
Sort By: Most Recent | Popular Filter: All | Bookmarks | Topics Simple Middle
2More

Feedback on "Large scale app development MVP article" - Google Web Toolkit | Google Groups - 0 views

groups.google.com/...dcfac548dae39873 mvp gwt
shared by Esfand S on 03 Jun 10 - Cached
  • It however clarify things about how Google sees MVP in GWT. They're even adding some MVP "framework" to GWT 2.1 (IsWidget and Activities, where an Activity is more or less your presenter, from what I understood).
  • RequestFactory on the other hand is a new thing for efficient CRUD operations on entity objects, which plugs more-or-less directly into the new Data widgets. Those widgets do blur the line a bit, but they're not really about presentation "logic", and they're somehow MVP- based themselves.
1More

Feedback on "Large scale app development MVP article" - Google Web Toolkit | Google Groups - 1 views

groups.google.com/...ecabbba0dbea6ace gwt mvp tip
shared by Esfand S on 02 Jun 10 - Cached
  • There are a few things that you should keep in mind before you try to understand the MVP pattern    1. You don't have reflection or observer/observable pattern on the client    side.    2. Views depend on DOM and GWT UI Libraries, and are difficult to    mock/emulate in a pure java test case Now, to answer some of your questions
1More

Feedback on "Large scale app development MVP article" - Google Web Toolkit | Google Groups - 0 views

groups.google.com/...49bce7c65ee44f8b gwt mvp tip
shared by Esfand S on 02 Jun 10 - Cached
  • There are a few things that you should keep in mind before you try to understand the MVP pattern    1. You don't have reflection or observer/observable pattern on the client    side.    2. Views depend on DOM and GWT UI Libraries, and are difficult to    mock/emulate in a pure java test case Now, to answer some of your questions
4More

ValueStoreAndRequestFactory - google-web-toolkit - Discussion of ValueStore and Request... - 1 views

code.google.com/...ValueStoreAndRequestFactory mvp gwt top
shared by Esfand S on 20 May 10 - Cached
  • Databinding is about making two properties in sync. The target property could be a JPA entity, but also another widget property. From a Databinding framework perspective, a JPA entity object of any RPC interface should not be tied to the framework.
  • The intent is that ValueBox? would also be useful for data binding of plain old client side JavaBeans?, without any need for the Id and Property classes. I can define a ValueBox? interface tied to a set of bean classes and have it move their fields to and from HasValue? instances, enforcing validations in the process. I can set up this binding myself via calls like valueBox.setSubcription(bean, fieldNameString). Or I can GWT.create an EditorSupport? object to make those calls for me (which is why they didn't appear in the sketch).
  • Re: why re-invent a wheel, we want our new data backed widgets to play very nice in an asynchronous world — I'll tell you what values I want, you push them into me when they show up, and as they get updated. My impression of the existing frameworks is that they don't play naturally in that world.
  • ...1 more annotation...
  • RequestFactory? is intended as another, optional layer on top of this, to aid in dealing with server side ORM. Shared Id instances refer to server side Entities. They and Property instances are used as arguments to command objects (Requests) to make asynchronous RPC calls for the values of fields on these objects, and to edit them. (The @ServerType? annotation is to simplify the use of the ids server side.) ValueBox? and EditorSupport? can also be used to bind these objects and the UI that displays them. I figure we'll provide a script and a servlet that can grovel through JPA service interfaces and generate / maintain the Id and Property definitions, and that others can easily be spun for other persistence frameworks.
1More

Google integrating MVP tools in GWT 2.1 M1... - GWTP | Google Groups - 1 views

groups.google.com/...862cab91ccb28d40 gwt mvp roo
shared by Esfand S on 22 May 10 - Cached
  • from what it seems to me the GWT 2.1 MVP is quite different than GWTP (and from GWT-MVP), and is not targeted to the same audience. I would say it is targeted to developers who want to develop Spring-GWT applications in a Grails/RoR way.
4More

What's Coming in GWT 2.1? - Google Web Toolkit - Google Code - 1 views

code.google.com/...ReleaseNotes.html gwt mvp
shared by Esfand S on 22 May 10 - Cached
  • the data presentation widgets use a 'flyweight' design. Rather than being a container of other widgets, which can tend to be heavy, they build up chunks of HTML that is injected into the DOM. This not only speeds up initialization, but also reduces the event handling overhead that can slow down user experience when there are hundreds of widgets within a view.
  • The MVP Framework is an app framework that makes it easy for you to connect Data Presentation Widgets with backend data. Using this framework you create views that are focused on displaying data, Activities and an AcivityManager which are the "presenters", responsible for handling self-contained actions, and RequestFactories that fetch and propagate model changes throughout your app.
  • To make developing apps of this style easier, the 1.1 M1 release of Spring Roo, can generate and maintain the boilerplate code associated with connecting your app's components with GWT's MVP Framework.
  • ...1 more annotation...
  • To upgrade to 2.1 M1, simply do the following Download GWT 2.1 M1 from the download page and unpack it to the directory of your choice. If you use Eclipse to develop, you should also download the Google Plugin for Eclipse from the same download page. Update your GWT project build path to use the latest gwt-user.jar and gwt-dev.jar (and any other GWT jars that you included on your classpath). Replace references to gwt-dev-<platform>.jar with the location of the new gwt-dev.jar (there is no longer a platform specific suffix). Update any run configurations or application compile and shell scripts to include the latest JARs in the classpath (same JARs as mentioned in step 2). Run a GWT compilation over your project to generate the latest GWT application files for your project. Deploy the latest GWT application files to your web server.
3More

What's Coming in GWT 2.1? - Google Web Toolkit - Google Code - 1 views

code.google.com/...ReleaseNotes.html gwt mvp widget
shared by Esfand S on 20 May 10 - Cached
  • MVP Framework The MVP Framework is an app framework that makes it easy for you to connect Data Presentation Widgets with backend data. Using this framework you create views that are focused on displaying data, Activities and an AcivityManager which are the "presenters", responsible for handling self-contained actions, and RequestFactories that fetch and propagate model changes throughout your app. To make developing apps of this style easier, the 1.1 M1 release of Spring Roo, can generate and maintain the boilerplate code associated with connecting your app's components with GWT's MVP Framework.
  • the data presentation widgets use a 'flyweight' design. Rather than being a container of other widgets, which can tend to be heavy, they build up chunks of HTML that is injected into the DOM. This not only speeds up initialization, but also reduces the event handling overhead that can slow down user experience when there are hundreds of widgets within a view.
  • To upgrade to 2.1 M1, simply do the following Download GWT 2.1 M1 from the download page and unpack it to the directory of your choice. If you use Eclipse to develop, you should also download the Google Plugin for Eclipse from the same download page. Update your GWT project build path to use the latest gwt-user.jar and gwt-dev.jar (and any other GWT jars that you included on your classpath). Replace references to gwt-dev-<platform>.jar with the location of the new gwt-dev.jar (there is no longer a platform specific suffix). Update any run configurations or application compile and shell scripts to include the latest JARs in the classpath (same JARs as mentioned in step 2). Run a GWT compilation over your project to generate the latest GWT application files for your project. Deploy the latest GWT application files to your web server.
11More

Large scale application development and MVP - Part II - 0 views

code.google.com/...mvp-architecture-2.html mvp top best gwt
shared by Esfand S on 13 May 10 - Cached
  • segment the code that declares the UI from the code that drives the UI.
  • we want the our ContactsPresenter to implement a Presenter interface that allows our ContactsView to callback into the presenter when it receives a click, select or other event. The Presenter interface defines the following:   public interface Presenter<T> {    void onAddButtonClicked();    void onDeleteButtonClicked();    void onItemClicked(T clickedItem);    void onItemSelected(T selectedItem);  }
  • The first part of wiring everything up is to have our ContactsPresenter implement the Presenter interface, and then register itself with the underlying view. To register itself, we'll need our ContactsView to expose a setPresenter() method:   private Presenter<T> presenter;  public void setPresenter(Presenter<T> presenter) {    this.presenter = presenter;  }
  • ...8 more annotations...
  • Note that our ContactsView is now ContactsViewImpl<T> and implements ContactsView<T>. This is so that we can pass in a mocked ContactsView instance when testing our ContactsPresenter. Now in our AppController, when we create the ContactsView, we can initialize it with the necessary ColumnDefinition(s).
  • With the ColumnDefinition(s) in place, we will start to see the fruits of our labor. Mainly in the way we pass model data to the view. As mentioned above we were previously dumbing down the model into a list of Strings. With our ColumnDefinition(s) we can pass the model untouched.   public class ContactsPresenter implements Presenter,    ...    private void fetchContactDetails() {      rpcService.getContactDetails(new AsyncCallback<ArrayList<ContactDetails>>() {        public void onSuccess(ArrayList<ContactDetails> result) {            contactDetails = result;            sortContactDetails();            view.setRowData(contactDetails);        }        ...      });    }    ...  } And our ContactsViewImpl has the following setRowData() implementation:   public class ContactsViewImpl<T> extends Composite implements ContactsView<T> {    ...    public void setRowData(List<T> rowData) {      contactsTable.removeAllRows();      this.rowData = rowData;      for (int i = 0; i < rowData.size(); ++i) {        T t = rowData.get(i);        for (int j = 0; j < columnDefinitions.size(); ++j) {          ColumnDefinition<T> columnDefinition = columnDefinitions.get(j);          contactsTable.setWidget(i, j, columnDefinition.render(t));        }      }    }    ...  } A definite improvement; the presenter can pass the model untouched and the view has no rendering code that we would otherwise need to test.
  • Code Splitting is the act of wrapping segmented pieces of your application into "split" points by declaring them within a runAsync() call. As long as the split portion of your code is purely segmented, and not referenced by other parts of the app, it will be downloaded and executed at the point that it needs to run.
  • We've figured out how to create the foundation for complex UIs while sticking to our requirement that the view remain as dumb (and minimally testable) as possible, but that's no reason to stop. While functionality is decoupled, there is still room for optimization. Having the ColumnDefinition create a new widget for each cell is too heavy, and can quickly lead to performance degradation as your application grows. The two leading factors of this degradation are: Inefficiencies related to inserting new elements via DOM manipulation Overhead associated with sinking events per Widget To overcome this we will update our application to do the following (in respective order): Replace our FlexTable implementation with an HTML widget that we'll populate by calling setHTML(), effectively batching all DOM manipulation into a single call. Reduce the event overhead by sinking events on the HTML widget, rather than the individual cells. The changes are encompassed within our ContactsView.ui.xml file, as well as our setRowData() and onTableClicked() methods. First we'll need to update our ContactsView.ui.xml file to use a HTML widget rather than a FlexTable widget.
  • The above code is similar to our original setRowData() method, we iterate through the rowData and for each item ask our column definitions to render accordingly. The main differences being that a) we're expecting each column definition to render itself into the StringBuilder rather than passing back a full-on widget, and b) we're calling setHTML on a HTML widget rather than calling setWidget on a FlexTable. This will decrease your load time, especially as your tables start to grow.
  • To reiterate, we're reducing the overhead of sinking events on per-cell widgets, and instead sinking on a single container, our HTML widget. The ClickEvents are still wired up via our UiHandler annotations, but with this approach, we're going to get the Element that was clicked on and walk the DOM until we find a parent TableCellElement. From there we can determine the row, and thus the corresponding rowData.
  • Our current solution is to have our presenters pass a dumbed down version of the model to our views. In the case of our ContactsView, the presenter takes a list of DTOs (Data Transfer Objects) and constructs a list of Strings that it then passes to the view. public ContactsPresenter implements Presenter {  ...  public void onSuccess(ArrayList<ContactDetails> result) {    contactDetails = result;    sortContactDetails();    List<String> data = new ArrayList<String>();    for (int i = 0; i < result.size(); ++i) {      data.add(contactDetails.get(i).getDisplayName());    }    display.setData(data);  }  ...} The "data" object that is passed to the view is a very (and I mean very) simplistic ViewModel — basically a representation of a more complex data model using primitives. This is fine for a simplistic view, but as soon as you start to do something more complex, you quickly realize that something has to give. Either the presenter needs to know more about the view (making it hard to swap out views for other platforms), or the view needs to know more about the data model (ultimately making your view smarter, thus requiring more GwtTestCases). The solution is to use generics along with a third party that abstracts any knowledge of a cell's data type, as well as how that data type is rendered.
  •         // TODO: Really total hack! There's gotta be a better way...        Element child = cell.getFirstChildElement();        if (child != null) {          Event.sinkEvents(child, Event.ONFOCUS | Event.ONBLUR);        }
3More

An MVP-compatible EnumListBox for GWT « TurboManage - 2 views

turbomanage.wordpress.com/...compatible-enumlistbox-for-gwt gwt mvp listbox enum
shared by Esfand S on 13 May 10 - Cached
  • If you start thinking about the different kinds of viewers you can create you’ll see that most of them behave in the same way. Whether you display your list of boolean values (in this case) as a single select listbox (with one value being true at a time) or as a group of radio buttons or as a multiselect list (all selected are true) or as a group of check boxes the only thing separating the class ListBoxViewer from GroupViewer (for lack of a better name) would be what widgets they choose to use. They can both inherit SelectableListViewer which holds most of the logic and a setMultiSelect(boolean enabled) method. Later on when you want to create a table with a check box on each row that selects the row for some future action it’s just more of the same old.
  • So you have a ListBoxViewer that holds the listBox and has a getWidget() to give the widget to your panel.The viewer takes an instance of the interface ListBoxFormat in its constructor. The format implementation has a getValue(E element) that returns the value to display in the llistbox. The viewer has the required methods to set the values of the listbox and get a list of the currently selected values and so on. Probably along the way of what you’re planning to do next. By using viewers and formats you can do the same thing for other widgets like tables as well. So populating a table with values is as easy as tableViewer.setSource(aListOfTableRowObjects) where the objects in the list can by of any type that you can write a TableFormat for (with a getColumnValue(int column, E element) method). GlazedLists does this for the desktop (Swing and SWT/JFace). The cool thing there is that the viewer is aware of changes to the actual input list outside of the viewer, I don’t think that’s possible in GWT yet
  • the constructor uses an EnumTranslator to populate the labels in the ListBox. This allows you to use a standard GWT ConstantsWithLookup inteface to supply localized text for the enum values instead of the constant names. ConstantsWithLookup is just like Constants, but with the important ability to find a value dynamically without invoking a method corresponding to the property name.
« First ‹ Previous 141 - 160 of 220 Next › Last »
Showing 20▼ items per page