Showing posts with label Place. Show all posts
Showing posts with label Place. Show all posts

Saturday, December 28, 2013

GWT nesting activities implementing Thomas Broyer proposal

This article has been moved here

http://ronanquillevere.github.io/2013/12/28/not-nesting-activities.html





-- old version --







Hi everyone,

I tried to implement Thomas Broyer's idea to solve the nesting activities problem: http://blog.ltgt.net/gwt-21-activities-nesting-yagni/

So I created a Github project, have a look and do not hesitate to comment : https://github.com/ronanquillevere/GWT-Multi-Activities

Hope it will help some of you.

I will try to have a look to slotted ASAP https://code.google.com/p/slotted/ which is a framework that does exactly the opposite ! 

Friday, August 2, 2013

Nested Activities : an alternative with Presenters

This article has been moved here

http://ronanquillevere.github.io/2013/08/02/presenter-for-nesting.html





-- old version --






If you are reading this article it means you probably have already read the article called GWT 2.1 Activities – nesting? YAGNI! http://blog.ltgt.net/gwt-21-activities-nesting-yagni/ by Thomas Broyer https://plus.google.com/113945685385052458154?rel=author . If you did not, I suggest to have a look at his article.

In this article I will reformulate the idea explained by Thomas Broyer and propose another solution and try to compare them.

Activity Place Pattern


First you need to understand how the Activities and Places pattern works in detail. Below is a quick overview with the major objects involved.



When you go from one Place to another, at some point, the framework will throw a PlaceChangeEvent. Inside this event you will find a Place object corresponding to the URL of the Place your are trying to go to.

This event will be listened by the ActivityManager. The ActivityManager will call the ActivityMapper to give him back the Activity (instance) corresponding to that new Place.

Then the ActivityManager will try to start() this Activity.

So the first time you design an application using the Activities and Places pattern you will probably have something like : one web page = one url = one activity

But if your web page is complex ,with distinct regions inside (a header, a side bar, a content area etc.), with components inside that you might want to reuse in other pages you end up trying to create sub-activities or "nested" activities as Thomas call them.

One Place - Many Activities


This is how I would describe Thomas' solution. Again, please have a look at his article http://blog.ltgt.net/gwt-21-activities-nesting-yagni/ .

The idea is the following


1 ActivityManager + 1 ActivityMapper for each region of a web page
All ActivityManagers share the same Eventbus
1 layout for all the pages of the application. This layout defines all the possible regions
If a region is not needed on a certain page, the corresponding ActivityMapper will return null and the ActivityManager will not display the region (meaning the region will be hidden)

So let's say you want to go to a new Place in your application. The PlaceChangeEvent will be fired. All ActivityManagers will receive the event ( they all share the same Eventbus ) each of them will call his own ActivityMapper returning a specific Activity.

If you take the example of a "side bar" region (left part of your web page). On a Place called placeA, the ActivityMapper will return an activityA, but on a placeB, the ActivityMapper may return an activityB or may return null thus hiding the "side bar region".

One Place - One Activity - Many Presenters


Here is my proposal, another way of doing this is the following: You need to introduce another interface which is a kind of Presenter and that is not managed by the Activities and Places framework.

Your Presenter interface should probably have those kind of methods (the presenter interface should probably also have some kind of getView() method).

public interface Presenter {
    void init();
    void dispose();
   ...
}

They will be initialized/disposed by the Activity when it starts or stops.

An Activity will contain as many presenters as regions in the page (and presenters might contain nested presenters inside them). The Activity can have a view which is a DockLayoutPanel and when the Activity starts, it can add the presenters' views inside the different areas of its DockLayoutPanel view.



So the start method of the activity should look like this (you would probably pass the Eventbus to your presenters in the init method but I just want to focus on the idea, not the real implementation).

Activity.start(){
...
    headerPresenter.init();
    getView().addNorth(headerPresenter.getView());

    sideBarPresenter.init();
    getView().addLeft(sideBarPresenter.getView());

    contentPresenter.init();
    getView().add(contentPresenter.getView());
...
}

The disposal of the presenters should be called when the activity stops.

Of course your Activity can have a simpler layout for its view than the DockLayoutPanel.

So instead of having many ActivityManagers, you can have only one. The activity will be the master of ceremony between your different presenters. And you will have one Activity per Place.

You could use the Activity Interface for your Presenters but I think it is kind of dirty ...

Pros


  • One ActivityManager
  • One ActivityMapper
  • One Activity per Place

Cons


  • The history can be tricky to handle if you want to change the state of your presenters and update the URL without "really" changing the place
  • Creating a new Presenter interface and being sure that presenters are initialized/disposed correctly changing the main layout from place to place
Ok I think I will stop here, I will probably add some details in the futur if it is not understandable enough.

Tell me what you think of it, I am sure my proposal is a bad idea :D. 

Sunday, March 3, 2013

GWT Activities and Places framework Introduction

This article has been moved here

http://ronanquillevere.github.io/2013/03/03/activities-places-intro.html





-- old version --







Hello everyone,

In the following article I will try to explain and clarify the Google Activities and Places framework.

You can have a look at the following article for more thoughts on nesting activities : http://wpamm.blogspot.tw/2013/08/nested-activities-alternative-with.html

Model View Presenter (MVP)


For a lot of people, it is not clear wether or not the Activities and Places framework is equivalent to MVP. MVP is a coding pattern. It was pushed by Google in their GWT framework as an improvement of the classical MVC pattern http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Classical MVC pattern




MVP pattern 




The difference is that the model and the view should not know each other.

The consequence is that the view should be as dumb as possible. No intelligence should be coded in the view. The view is only the graphical representation of the component. All the behaviors should be coded in the presenter. The events are transmitted by the view to the presenter.

This pattern makes it really simple to replace a view component (this can be really useful to test the application with mocked views ...)

Check out the Google I/O 2009 for more explanation on the topic (go to 21m30s)




Other MVP implementations for GWT have been developed and released before Google released their own in GWT 2.2. Example gwtmvp. http://www.gwtmpv.org/index.html

Activities and Places

Introduction

As stated by the documentation https://developers.google.com/web-toolkit/doc/latest/DevGuideMvpActivitiesAndPlaces

The Activities and Places framework allows you to create bookmarkable URLs within your application.

So Activities and Places are a lot more than just an MVP framework. Nonetheless this framework has been build around the MVP pattern. The MVP part of this framework is represented by the Activity interface

public interface Activity {

  String mayStop();

  void onCancel();

  void onStop();

  void start(AcceptsOneWidget panel, EventBus eventBus);
}

Here you find the typical methods you will find in all MVP implementations.
start() : initialize some stuff in a start() like event registrations, add your view to the dom etc.
onStop() : clean some stuff (and memory) like event registrations etc.

Sometimes these methods are called bind() and unbind() in other MVP frameworks.

So an Activity is your Presenter. All your logic should be found there. This is the glue between your view (FlowPanel, AbsolutePanel etc...) and your model (your data).

Places & history workflow


So now let's take a look a the Activity Place framework in detail. To do so I just used the GWT Activity Place MVP tutorial code found here http://code.google.com/p/google-web-toolkit/downloads/detail?name=Tutorial-hellomvp-2.1.zip . I made it work with eclipse and launched the GWT application.

Then I entered the following url in my brower : http://127.0.0.1:8888/hellomvp.html?gwt.codesvr=127.0.0.1:9997#GoodbyePlace:World!

Here is what happened



A better version of the diagram focused on the second part




Once the application is launched, the PlaceHistoryHandler get the url token from the Historian. Then the PlaceHistoryHandler calls the PlaceHistoryMapper to get the Place corresponding to the url token. To do so the PlaceHistoryMapper calls the PlaceTokenizer.

Once it has the Place, the PlaceHistoryHandler ask the PlaceController to go to the new Place. It is a kind of redirection. The PlaceController simply sends a PlaceChangedEvent with the new Place wrapped inside.

The ActivityManager listen to this event and asks the ActivityMapper to give back the Activity corresponding to the Place. Then the ActivityManager starts the Activity.


@Override
public void start(AcceptsOneWidget containerWidget, EventBus eventBus)
{
    GoodbyeView goodbyeView = clientFactory.getGoodbyeView();
    goodbyeView.setName(name);
    containerWidget.setWidget(goodbyeView.asWidget());
}


At the end of the start method, the containerWidget (in this case the whole HTML page) set its widget to the new view.

Responsibilities


Here are the some of the main objects and their responsibilities

PlaceHistoryMapper : get a Place from a String (url token).
ActivityMapper : get an Activity from a Place.
ActivityManager : starts, stops the activities (it is the Master of Ceremony)

These are really the objects you want a look into if you want to change something in the frameworks like adding parameters to your urls ...

I think I will end there this article as it is long enough. I will probably detail some other things in other articles. Hope it helped !