Large scale application development and MVP - Part II - Google Web Toolkit - Google Code - 0 views
-
itself
-
anonymous on 18 Jan 11The View Implementation
-
-
@UiHandler("
-
presenter.onAddButtonClicked();
- ...91 more annotations...
-
onAddButtonClicked
-
eventBus.fireEvent(new AddContactEvent());
-
presenter needs to know more about the view
-
view needs to know more about the data model
-
data types are typically homogeneous within column borders
-
ColumnDefinition abstract class
-
houses the any type-specific code (this is the third party mentioned above)
-
ColumnDefinition
-
ColumnDefinition(s) would be created outside of the presenter
-
we can reuse its logic regardless of what view we've attached ourself to
-
update our views such that we can set their ColumnDefinition(s).
-
setColumnDefinitions
-
this.columnDefinitions = columnDefinitions;
-
so that we can pass in
-
a mocked ContactsView instance when testing our ContactsPresenter
-
in our AppController, when we create the ContactsView,
-
new ContactsViewColumnDefinitions().getColumnDefinitions();
-
we can initialize it with the necessary ColumnDefinition(s).
-
contactsView.setColumnDefiniions(
-
-
With our ColumnDefinition(s) we can pass the model untouched.
-
As mentioned above we were previously dumbing down the model into a list of Strings
-
current solution
-
List<String> data
-
display.setData(data);
-
how that data type is rendered.
-
use generics
-
third party that abstracts
-
knowledge of a cell's data type
-
stringing together a list of these classes
-
providing the necessary render()
-
and isClickable()/isSelectable() override
-
ContactsViewColumnDefinitions<ContactDetails>
-
columnDefinitions = new ArrayList<ColumnDefinition<ContactDetails>>()
-
ColumnDefinition<T>
-
ContactsPresenter
-
ContactsViewImpl
-
ColumnDefinition<T> columnDefinition = columnDefinitions.get(j);
-
the presenter can pass the model untouched
-
the view has no rendering code
-
that we would otherwise need to test. And the fun doesn't stop there.
-
presenter.onItemClicked(
-
presenter.onItemSelected
-
ClickEvent
-
cell.getCellIndex()
-
columnDefinition.isClickable()
-
SelectEvent
-
columnDefinition.isSelectable()
-
return shouldFireClickEvent;
-
return shouldFireSelectEvent;
-
respond to user interaction in different ways based upon the cell type that was clicked
-
use them for rendering purposes
-
defining how to interpret user interactions
-
we're going to remove any application state from the ContactsView
-
replace the view's getSelectedRows() with a SelectionModel
-
The SelectionModel is nothing more than a wrapper around a list of model objects.
-
ContactsPresenter holds on to an instance of this class
-
onItemSelected
-
Having the ColumnDefinition create a new widget for each cell is too heavy
-
Replace our FlexTable implementation with an HTML widget
-
calling setHTML()
-
Reduce the event overhead by sinking events on the HTML widget
-
rather than the individual cells
-
update our ContactsView.ui.xml file to use a
-
HTML widget rather than a FlexTable widget.
-
<g:HTML ui:field="contactsTable">
-
Inefficiencies related to inserting new elements via DOM manipulation Overhead associated with sinking events per Widget
-
for each item ask our column definitions to render accordingly
-
each column definition
-
render itself into the StringBuilder
-
rather than passing back a full-on widget
-
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.
-
we're reducing the overhead of sinking events on per-cell widgets
-
instead sinking on a single container
-
ClickEvents are still wired up via our UiHandler annotations
-
get the Element that was clicked on
-
and walk the DOM until we find a parent TableCellElement
-
we can determine the row
-
shouldFirdClickEvent() and shouldFireSelectEvent()
-
to take as a parameter a TableCellElement rather than a HTMLTable.Cell.
-
faster startup times via Code Splitting.
-
runAsync() points
-
split portion of your code is purely segmented
-
not referenced by other parts of the app
-
it will be downloaded and executed at the point that it needs to run
-
Do we really want to download all of that code before the user even logs in?
-
Not really.
-
simply grab the login code, and leave the rest for when we actually need it
-
wrap the code that creates the ContactsView and ContactsPresenter in a runAsync() call
-
as optimizations such as this one become easier and easier to implement.
