We've been using the recommended GWT approach of building parts of our application in an MVP manner. The logic we use is based on Google's examples - the Presenter fetches/prepares data and sets it on the View, and the View contains a reference to the Presenter which it calls (e.g. in UiHandlers).
Some parts of the application which we built should be reused in other views. For example - a view which is sometimes the "main view" of a part of the application - can be used inside a pop-up in another part of the application (of course, the views/presenters are initialized differently in this other case, but basically it is the same thing).
What would be the correct approach to do stuff like this? I cannot seem to find a suitable one without resorting to ugly hacky stuff.
For example - if I put the presenter of the reused component inside the main view - it is easy to initialize the reused component, but it is ugly to receive a result back in the main presenter. This can be solved by passing a runnable or creating a custom handler or passing the parent presenter itself to the reused presenter.
All of these approaches don't seem right to me though and seem ugly.
Any ideas/experiences?
What you're describing is a view being able to be controlled by 2 distinct presenters. Abstracting those presenters behind a common API, in the form of an interface, should be enough.
You can also see it as a composite widget being used within two distinct views. The composite widget would then expose events and a public API that both views could wire to their specific presenters.
See Activites and Places,It can help you to desing and structure you app.
https://developers.google.com/web-toolkit/doc/latest/DevGuideMvpActivitiesAndPlaces
.
Related
I try to understand how the gwt example about activities and places works (https://developers.google.com/web-toolkit/doc/latest/DevGuideMvpActivitiesAndPlaces). I am wondering why they define an interface for the presenter. I know the view interface is helpful to exchange the view easily. But what's the use of the presenter interface?
Its always a best practice to design application with interfaces rather than concrete classes.
Reference - What does "program to interfaces, not implementations" mean?
Reference - WikiPedia example for MVP
Another key factor in MVP architecture to make your design pretty clean is defining an Presenter interface(As we already know the beauty of interface OOP conceptin JAVA).
Presenter interface that allows our View to callback into the presenter when it receives an event. The Presenter interface defines the following:
public interface Presenter<T> {
void onAddButtonClicked();
}
And then you can set the presenter to your view like below
private Presenter<T> presenter;
public void setPresenter(Presenter<T> presenter) {
this.presenter = presenter;
}
Finally when your PresenterConcreteClass implements your presenter interface those implementations will triggers.
Besides the cleanliness of using an interface, there's also no reason you wouldn't test your view. You could use end-to-end tests, but you can also simply use a GWTTestCase where you instantiate the view and use a mock presenter.
You'd then be able to test that “when I click on this button, it should call this method from the presenter with the values X, Y and Z as arguments”, or “when I call this method of the view with those arguments, then such widget should turn red and that other one should hide/collapse/show/whatever”.
I've also used it, once, to similarly build a simple testbed app to manually test the UI with fake data. The app consisted of buttons to simulate the presenter calling the view with fake data, and handled the presenter calls back from the view with Window.alert or similar things. You'd launch the app in your browser and click here and there and validate that the view works as expected.
This can be useful when you later add a field to your form, to make sure you correctly wire it with the presenter. You don't want to setup your GWT-RPC/RequestFactory/whatever services from the real presenter, when a unit-test could be enough.
2 big reasons off the top of my head (there may be others too...)
Testing: Your Presenter then does not have to have a direct reference to the View, which is nice because the View contains GWT Objects (i.e: any Widget) which cannot be used in a standard Unit Test Case: Any GWT Object must have a JS container (i.e: Browser, or GWTTestCase) to be instantiated; A JUnit test case cannot use a Browser; GWTTestCase runs VERY slow, so you should prefer not to have to use it. Without the interface, the Presenter would have to reference the View's methods by a direct reference to the View; that means when testing the Presenter, you must instantiate the View, which must instantiate its Widgets (which at that point require the GWTTestCase for the Widgets). And all you should be aiming to do in the 1st place is to test the logic, which should be completely in the Presenter to avoid GWTTestCase... With the Display interface, you can do just that: Focus on testing the Presenter, without the complication of instantiating the View (which has its own degree of instantation complication) and messing around then necessarily with GWTTestCase
Have multiple Views for the same Presenter: [I think you would only ever do this if you have different platforms (i.e: mobile App vs. browser) which each require their own View (since a mobile App version of the View is rendered differently from a browser View, since they are different platforms with different GUI entities)]. The multiple Views would then all just implement the Display interface in their separate ways. Then the single Presenter can contain the logic that is the same for all Views, be used for all the different Views, and all View implementations are guaranteed to follow the same expectations (which are the codification in the Display interface) of that single Presenter! This is a manifestation of the OOP best practice of designing with interfaces, which #SSR Answers.
Lets say that on all my views, or generally at any time in my app, I want to be able to show an error message popup, and it always looks the same. How do I do that?
First thought is having all my view models extend a base view model which facilitates these things, but after that, do I have this base view model actually create the UI widgets and display them?
thanks,
Mark
If you've got some common functionality that you want to provide across a range of views, then you can implement a base class that inherits from the PhoneApplicationPage, and then derive all your classes from that class instead. The XAML for your pages then looks like this:
<local:BasePage xmlns ...
xmlns:local="clr-namespace:MyNamespace"
x:Class="MyNamespace.MyPage">
However, you will not be able to define common UI components in the XAML for your base page. If you wanted to have common UI components you would have create them manually in the code-behind for the base page, perhaps in a handler for the Loaded event, but I think a better solution would be to provide your common UI in a UserControl, which you then add to each of your pages.
If you want to show a Toast or Message Box, then I would recommend the ToastRequestTrigger and MessageBoxRequestTrigger from the Silverlight Toolkit as described in the patterns & practices WP7 Developer Guide.
you could probably define an event on base view model, which is fired inside view model whenever an error occurs, then in view, you can subscribe to this event and display the popup. You can carry error context in EventArgs of the fired event.
Additionally you could unify the logic for displaying the popup but that's probably another story :)
This is testable and nicely decoupled from the view.
Hope this helps,
Robert
I am trying to use CellTree, i am confused about placement of class implementing TreeViewModel, This class will need Collection of elements required to be rendered as tree if this is view type class i need to push collection from the presenter. If its a Presenter class i can directly call the server function and get the collection.
I am finding it more near to Presenter.... please sugget
According to GWT docs,
A key concept of MVP development is
that a view is defined by an
interface. This allows multiple view
implementations based on client
characteristics (such as mobile vs.
desktop)
So, looks like Presenter should know neither about data presentation widgets used in view implementation, nor about specific ViewModels and data providers used by these data presentation widgets (since data presentation widgets may be changed). ViewModels are generally coupled with particular way to implement data presentation, so I usually consider them as a part of View.
I usually create presenter methods like getObjectsList(params), which return array / list of required data, and then transform these results to ViewModel.
BTW, it would be great to hear other opinions :)
We are using the GWT-Presenter framework and attempting to use CellTable to put together an updateable grid. It seems as though several of the GWT constructs for CellTable don't lend themselves to easily breaking up the logic into clean view and presenter code.
Examples: 1) Within the View's constructor, the CellTable is defined and each column is created by anonymous inner classes that extend the Column class to provide the onValue() method. 2) The FieldUpdater interface must be implemented to provide logic to execute when a user alters data in a cell. This seems like it would best fit in the Presenter's onBind() method, but FieldUpdaters often need access to the Cell or Column which belong in the view. CellTable does not have accessor methods to get hold of the Columns or Cells, so it seems the only way for the Presenter to get them is for me to create a multitude of member variables on the View and accessors on my Display interface.
Can anyone provide good examples for dealing with CellTable in GWT-Presenter or a comparable MVP
I think the main point of GWT MVP is that Presenters (Activities in 2.1) do not depend on View implementation, so that you can easily swap in mock Views for easy testing.
Further, it's OK to have Views that depend on Presenters (= call presenter methods), but not vice versa (well yes, but via interface).
Usually I just keep Presenter reference inside View, so that FieldUpdater anon inner classes can call methods in Presenter. You could put this methods in an interface, but it would make no sense since there is only one version of given type of Presenter.
Or, if you want to have things more decoupled, then just have View send a GWT Event which Presenter listens to.
Are you trying to avoid binding of Model class with View? i tried doing that for cellTable but it was becoming confusing to maintain code so i decided to let Model class couple with View. you can avoid this coupling by some generic arguments while creating view..
-Saket
The Data Presentation Widgets in GWT 2.1 seem to have it all sewn up: model, view and presenter. So how does all of this data presentation goodness fit in with MVP? For example; how might I associate presenter (aka Activity) instances with the nodes of a CellTree? And is that even something that I should be trying to do?
EDIT (elaboration):
Where does the TreeViewModel belong? Is it rightly part of the View, or part of the Presenter? And how does one obtain a reference to the ListDataModel for a sub-branch of the tree?
It's OK to give your view a reference to your presenter, and vice versa. If your CellTree needs access to your presenter, define a function like setPresenter in the CellTree.
Another solution would be to create EventHandlers that attach to your view, and then have your presenter listen for those events and respond by calling into the interface of your view. Less coupled, more verbose. I like to create generic interfaces for both my Presenter and my View to keep them totally separate but still avoid having to deal with EventHandlers.