Skip to main content

Home/ GWT - MVP/ Group items tagged event

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Esfand S

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);        }
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.
Esfand S

DockLayoutPanel MVP and events - Google Web Toolkit | Google Groups - 0 views

groups.google.com/...e7f3e5012619746b

mvp gwt gwt21 top place activity

shared by Esfand S on 15 Jul 10 - Cached
  • he generally adopted way of doing things in GWT is to have custom events go through the event bus. In this case, you're talking about "navigation", so maybe the concept of "place" would be better than "just" some custom event. I encourage you to look at gwt-platform, gwt- presenter and other MVP frameworks for GWT, and/or look at the Activity concept from the upcoming GWT 2.1. Using actvities, you'd have an ActivityManager managing your "center". The tree would use the PlaceController.goTo to navigate to a new "place". An ActivityMapper (that you passed to the ActivityManager in the constructor) would map the place to an Activity (a presenter), and the ActivityManager will manage the current Activity for the display it manages, i.e.it will stop() the current activity if its ok (willStop returns true) and then only start the new Activity, which will call the Display back to show its view. The tree would probably also listen to PlaceChangeEvent on the event bus to update the selected item depending on the current place (in case some other component calls the PlaceController.goTo)
Esfand S

DockLayoutPanel MVP and events - Google Web Toolkit | Google Groups - 0 views

groups.google.com/...e7f3e5012619746b

gwt mvp place activity gwt21

shared by Esfand S on 14 Jul 10 - No Cached
  • he generally adopted way of doing things in GWT is to have custom events go through the event bus. In this case, you're talking about "navigation", so maybe the concept of "place" would be better than "just" some custom event. I encourage you to look at gwt-platform, gwt- presenter and other MVP frameworks for GWT, and/or look at the Activity concept from the upcoming GWT 2.1.
  • Using actvities, you'd have an ActivityManager managing your "center". The tree would use the PlaceController.goTo to navigate to a new "place". An ActivityMapper (that you passed to the ActivityManager in the constructor) would map the place to an Activity (a presenter), and the ActivityManager will manage the current Activity for the display it manages, i.e.it will stop() the current activity if its ok (willStop returns true) and then only start the new Activity, which will call the Display back to show its view. The tree would probably also listen to PlaceChangeEvent on the event bus to update the selected item depending on the current place (in case some other component calls the PlaceController.goTo)
Esfand S

Gwt 2.1 Activities + Code splitting + Gin - Google Web Toolkit | Google Groups - 0 views

groups.google.com/...dfebec64e64c82fe

gwt mvp activity

shared by Esfand S on 08 Nov 10 - No Cached
  • I think the overall idea of activities is that they are short-lived instances, so they're effectively "lazily created" (actually, a new instance is created each time one is needed) and they don't need to be "awoken" because if they're not currently in use they're already "dead" and garbage collected. The ActivityManager (actually its associated ActivityMapper) will decide whether a particular activity is needed (and then instantiate it, possibly going through a GWT.runAsync for code splitting); the activity will listen to events its interested in *during its lifetime* (e.g. whether some object has changed or has been added or deleted, so it can update its view); but when it's done (stopped or cancelled), it's simply thrown away (the event bus passed to the start() method is a ResettableEventBus so all handlers have been automatically unregistered for you, which as a side effect allows the activity to be garbage collected). This is the (AIUI) intended use, but nothing forces you to write such short-lived instances: you can very well use singletons, but then you'll have the additional task of maintaining state between "runs" (start/stop or start/cancel), in which case your activity can listen to events from the event bus after being stopped/cancelled (just use the "real" event bus instead of the ResettableEventBus passed to the start() method); but it won't "ask to be revealed": navigation is handled at another layer, triggered on the PlaceController and handled by ActivityManagers.
Esfand S

Gwt 2.1 Activities + Code splitting + Gin - Google Web Toolkit | Google Groups - 0 views

groups.google.com/...f3f3ff778693fb41

gwt mvp gin codesplitting activity

shared by Esfand S on 07 Nov 10 - No Cached
  • I think the overall idea of activities is that they are short-lived instances, so they're effectively "lazily created" (actually, a new instance is created each time one is needed) and they don't need to be "awoken" because if they're not currently in use they're already "dead" and garbage collected. The ActivityManager (actually its associated ActivityMapper) will decide whether a particular activity is needed (and then instantiate it, possibly going through a GWT.runAsync for code splitting); the activity will listen to events its interested in *during its lifetime* (e.g. whether some object has changed or has been added or deleted, so it can update its view); but when it's done (stopped or cancelled), it's simply thrown away (the event bus passed to the start() method is a ResettableEventBus so all handlers have been automatically unregistered for you, which as a side effect allows the activity to be garbage collected). This is the (AIUI) intended use, but nothing forces you to write such short-lived instances: you can very well use singletons, but then you'll have the additional task of maintaining state between "runs" (start/stop or start/cancel), in which case your activity can listen to events from the event bus after being stopped/cancelled (just use the "real" event bus instead of the ResettableEventBus passed to the start() method); but it won't "ask to be revealed": navigation is handled at another layer, triggered on the PlaceController and handled by ActivityManagers.
Esfand S

Client session - Google Web Toolkit | Google Groups - 0 views

groups.google.com/...b62d03190a291c58

gwt mvp tip

shared by Esfand S on 16 Jul 10 - Cached
  • The way I would do is to define a application event (eg. LocationEvent<LocationHandler>) & handler encapsulating whatever data (ex. co ordinates) that you need to send and fire the event. First presenter fires the event when the mouse is clicked. Second Presenter handles the event and takes appropriate action.
Esfand S

GWT MVP - Google Web Toolkit | Google Groups - 0 views

groups.google.com/...b4dfa8514971e579

mvp mvc

shared by Esfand S on 13 May 10 - Cached
  • For your convenience, here is the net of it. With MVC, the model is thick with business rules and glue code to a data access layer. The view has lots of dependencies on the model. The controller is usually a framework component driven by some kind of configuration, usually XML based. With MVP, the model is lightweight POJOs. The view is mockable. It is the presenter that is heavy with glue code and business rules. The thinking here is that MVP is more suited for TDD than MVC. Another notable feature of MVP in GWT apps is the use of an event bus instead of hard coded event handler dependencies. Typically, that event bus is implemented as either the HandlerManager from GWT itself or the PropertyChangeSupport class from the GWTx library.
Esfand S

Ray Ryan, best practices and embracing asynchronicity - Google Web Toolkit | Google Groups - 0 views

groups.google.com/...642af0e6ef7317e0

mvp

shared by Esfand S on 13 May 10 - Cached
  • Doing this well depends on some form of centralized data retrieve dispatch/caching.  You make calls to this centralized service to get the objects by id that you are interested in.   It either finds them in cache and can return them immediately, or adds them to a queue of objects to retrieve.  After all requests have been made (ie on DeferredCommand), a single request is sent to retrieve all objects of all types needed.
  • You could use an event bus to indicate all the objects where data is now available. This could even be a single event instead of one for each object, and the event handlers can ask if their objects of interest are now available, avoiding multiple updates.
Esfand S

DockLayoutPanel MVP and events - Google Web Toolkit | Google Groups - 0 views

groups.google.com/...3d3bfedaeaf73f82

gwt gwt21 mvp place

shared by Esfand S on 16 Jul 10 - Cached
  • how does the PlaceChange Event gets fired?? As of 2.1M2, PlaceController still isn't bound to History, so only PlaceController#goTo will fire first a PlaceChangeRequestedEvent (which can be rejected) and then (if the first hasn't been rejected by listeners) a PlaceChangeEvent.
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"
Esfand S

Gwt 2.1 Activities + Code splitting + Gin - Google Web Toolkit | Google Groups - 0 views

groups.google.com/...f3f3ff778693fb41

gwt mvp activity

shared by Esfand S on 09 Nov 10 - No Cached
  • your ChatBoxPresenter isn't related to a "place", i.e. it's "awoken" based on a "business event", not a navigation event; and in other words, it's not an Activity: case made. Activities (ActivityManager) is limited in scope to reacting to place changes and navigation (not that you couldn't use the Activity "contract" in other scenarios, such as your "chat box", but the ActivityManager wouldn't be the right tool for the job, you'd have to find/write another "activity manager" for your different use case). In other words: GWT 2.1 Activities won't replace GWTP as a whole (and I believe, as I already said in the past, that it's not its goal either).
Esfand S

MVP multiple buttons/fields - Google Web Toolkit | Google Groups - 0 views

groups.google.com/...2a43b9d5b6bde6b8

gwt mvp snippet

shared by Esfand S on 13 Jul 10 - Cached
  • Start moving the code of addStock to the view. Try not to use widget code on the presenter. Then create an interface and implement in the presenter: class SomeViewHandlers {     void deleteStock(Stock code); } You already have the deleteStock method... so just add "implements SomeViewHandlers" to it. Then you need to give to the display that interface (generally in the constructor): display.setViewHandlers(this); Then in the presenter lease the method as: private void addStock(JsArray<Stock> stocks) { display.addStock(stocks); } And in the view copyPaste the code of the method and change this:  removeButton.addClickHandler(new ClickHandler() {        @Override        public void onClick(ClickEvent event) {          *viewHandlers.*deleteStock(code);        }      });
Esfand S

One v.s N EventBus - Google Web Toolkit | Google Groups - 2 views

groups.google.com/...1b79e96bed1f02b2

gwt mvp

shared by Esfand S on 02 Aug 10 - Cached
  • My application has several modules, and in each module, it may have different layout. Hence I have multiple level of Activity and in each module, I have an ActivityManager and ActivityMapper to create an appropriate Activity according to the Place or return null if not interested.  All the ActivityManagers are attached to a global Event bus.
Marco Antonio Almeida

GWT MVP Development with Activities and Places - Google Web Toolkit - Google Code - 2 views

code.google.com/...ideMvpActivitiesAndPlaces.html

gwt mvp development activities places

shared by Marco Antonio Almeida on 30 Oct 10 - No Cached
  • An activity in GWT 2.1 is analogous to a presenter in MVP terminology. It contains no Widgets or UI code. Activities are started and stopped by an ActivityManager associated with a container Widget. A powerful new feature in GWT 2.1 is that an Activity can automatically display a warning confirmation when the Activity is about to be stopped (such as when the user navigates to a new Place). In addition, the ActivityManager warns the user before the window is about to be closed.
  • A place in GWT 2.1 is a Java object representing a particular state of the UI. A Place can be converted to and from a URL history token (see GWT's History object) by defining a PlaceTokenizer for each Place, and the PlaceHistoryHandler automatically updates the browser URL corresponding to each Place in your app.
  • A key concept of MVP development is that a view is defined by an interface.
  • ...23 more annotations...
  • It is useful for views to extend IsWidget if they do in fact provide a Widget.
  • more complicated view that additionally defines an interface for its corresponding presenter (activity)
  • The Presenter interface and setPresenter method allow for bi-directional communication between view and presenter,
  •   @UiHandler("goodbyeLink")        void onClickGoodbye(ClickEvent e) {                presenter.goTo(new GoodbyePlace(name));        }
  • Because Widget creation involves DOM operations, views are relatively expensive to create. It is therefore good practice to make them reusable, and a relatively easy way to do this is via a view factory, which might be part of a larger ClientFactory.
  • Note the use of @UiHandler that delegates to the presenter
  • Another advantage of using a ClientFactory is that you can use it with GWT deferred binding to use different implementation classes based on user.agent or other properties. For example, you might use a MobileClientFactory to provide different view implementations than the default DesktopClientFactory.
  • ClientFactory A ClientFactory is not strictly required in GWT 2.1; however, it is helpful to use a factory or dependency injection framework like GIN to obtain references to objects needed throughout your application like the event bus.
  • Specify the implementation class in .gwt.xml:     <!-- Use ClientFactoryImpl by default -->    <replace-with class="com.hellomvp.client.ClientFactoryImpl">    <when-type-is class="com.hellomvp.client.ClientFactory"/>    </replace-with> You can use <when-property-is> to specify different implementations based on user.agent, locale, or other properties you define.
  • Activities Activity classes implement com.google.gwt.app.place.Activity. For convenience, you can extend AbstractActivity, which provides default (null) implementations of all required methods.
  • The first thing to notice is that HelloActivity makes reference to HelloView. This is a view interface, not an implementation.
  • The HelloActivity constructor takes two arguments: a HelloPlace and the ClientFactory
  • In GWT 2.1, activities are designed to be disposable, whereas views, which are more expensive to create due to the DOM calls required, should be reusable. In keeping with this idea, ClientFactory is used by HelloActivity to obtain a reference to the HelloView as well as the EventBus and PlaceController.
  • Finally, the goTo() method invokes the PlaceController to navigate to a new Place. PlaceController in turn notifies the ActivityManager to stop the current Activity, find and start the Activity associated with the new Place, and update the URL in PlaceHistoryHandler.
  • The non-null mayStop() method provides a warning that will be shown to the user when the Activity is about to be stopped due to window closing or navigation to another Place. If it returns null, no such warning will be shown.
  • In order to be accessible via a URL, an Activity needs a corresponding Place. A Place extends com.google.gwt.app.place.Place and must have an associated PlaceTokenizer which knows how to serialize the Place's state to a URL token.
  • It is convenient (though not required) to declare the PlaceTokenizer as a static class inside the corresponding Place. However, you need not have a PlaceTokenizer for each Place. Many Places in your app might not save any state to the URL, so they could just extend a BasicPlace which declares a PlaceTokenizer that returns a null token.
  • For even more control, you can instead implement PlaceHistoryMapperWithFactory and provide a TokenizerFactory that, in turn, provides individual PlaceTokenizers.
  • For more control of the PlaceHistoryMapper, you can use the @Prefix annotation on a PlaceTokenizer to change the first part of the URL associated with the Place
  • PlaceHistoryMapper PlaceHistoryMapper declares all the Places available in your app. You create an interface that extends PlaceHistoryMapper and uses the annotation @WithTokenizers to list each of your tokenizer classes.
  • ActivityMapper Finally, your app's ActivityMapper maps each Place to its corresponding Activity. It must implement ActivityMapper, and will likely have lots of code like "if (place instanceof SomePlace) return new SomeActivity(place)".
  • How it all works The ActivityManager keeps track of all Activities running within the context of one container widget. It listens for PlaceChangeRequestEvents and notifies the current activity when a new Place has been requested.
  • To navigate to a new Place in your application, call the goTo() method on your PlaceController.
Esfand S

GWT MVP Development with Activities and Places - Google Web Toolkit - Google Code - 0 views

code.google.com/...ideMvpActivitiesAndPlaces.html

gwt mvp navigation place activity

shared by Esfand S on 18 Nov 10 - No Cached
  • How to navigate To navigate to a new Place in your application, call the goTo() method on your PlaceController. This is illustrated above in the goTo() method of HelloActivity. PlaceController warns the current Activity that it may be stopping (via a PlaceChangeRequest event) and once allowed, fires a PlaceChangeEvent with the new Place. The PlaceHistoryHandler listens for PlaceChangeEvents and updates the URL history token accordingly. The ActivityManager also listens for PlaceChangeEvents and uses your app's ActivityMapper to start the Activity associated with the new Place. Rather than using PlaceController.goTo(), you can also create a Hyperlink containing the history token for the new Place obtained by calling your PlaceHistoryMapper.getToken(). When the user navigates to a new URL (via hyperlink, back button, or bookmark), PlaceHistoryHandler catches the ValueChangeEvent from the History object and calls your app's PlaceHistoryMapper to turn the history token into its corresponding Place. It then calls PlaceController.goTo() with the new Place. What about apps with multiple panels in the same window whose state should all be saved together in a single URL? GWT 2.1 does not attempt to provide a generic implementation of a composite Place; however, your app could create a CompositePlace, CompositeActivity, and CompositePlace.Tokenizer classes that delegate to the constituent members. In this case, only the composite objects would need to be registered with your app's ActivityMapper and PlaceHistoryMapper.
1 - 20 of 28 Next ›
Showing 20▼ items per page