I have a presenter which makes calls to Handler and get the data from server
same data is needed for another widget which is a miniature version of the existing view, but this will present all time in application.
Here what i have common is calls to handler, same handler and action objects.
What is the best way to design.
My possible solution :
1) Writing one Common class which has access to the dispatcher object (Inject through Ginjector), use the methods to get data.
But as per MVP architecture, dispatcher usage is restricted to presenter only, but this is non-presenter class.
AFAIK there is nothing about MVP which says that everything has to be done in the Presenter. It make sense to encapsulate logic which is common to multiple Presenters in one common class.
MVP is rather a pattern than a rule which is written in stone. So when it makes sense you can deviate a little bit from the pattern.
IMHO the common class is a the right approach.
Using a common class for handling the requests to the backend also makes it easy to implement caching and authentication for example.
There are two ways to do the communication between your Presenters and the common class:
Inject a singleton instance of your common class into all the Presenters that need the data. From the presenter you can call the a method on the common class and register a callback.
Inject the global EventBus into the common class and fire an Event (i.e. LoadDataEvent) from the corresponding Presenters and handle this Event in the common class. When the data is received from the backend you can fire another Event (i.e. DataLoadedEvent) from the common class and handle it in the corresponding Presenters.
Solution 1 is probably easier to implement but you have some coupling between the common class and the Presenter (it's not that bad if you use dependency injection).
Solution 2 requires a little bit more code (you have to define the Events) but provides a lot of flexibility and de-coupling. For example if you create a new Presenter that is also interested in the data you just need to register a Handler for the DataLoadedEvent in the Presenter and you are done.
If you are using event bus, your presenter(which makes calls to Handler) can fire events with new data and your miniature widget can register with event bus to receive them. This way only one presenter would call to server and anything on client can be notified using events.
Related
I'm reading about the Facebook Flux and I liked the pattern, but I don't understand why we need keep the store untouchable from the action creator. Facebook only says that it's part of "concern separation" and only the store should know how modify itself. Facebook disagrees with store setters like "setAsRead", but doesn't triggering an event on the action creator through the dispatcher that are captured on the store almost the same thing? And calling something like "setAsRead" doesn't exposes how the store are modifying itself.
Some guys say it causes coupling between the store and action creator, but triggering events on the dispatcher causes coupling between the pub/sub, store and action creator.
Keeping the stores untouchable from the action creator creates the need of the "waitFor". Wait For chains doesn't create more implicit coupling between stores? If some action need stores interacting on some given order why doesn't already make this on the action creator?
Do you guys know the cons to adopt a dispatchless approach with Facebook Flux?
If you implement setters in your store, you would completely break the uni-directional data flow principle that is arguably the central principle of the Flux pattern. Nothing would stop your components, or any other code, from directly manipulating the store's state. Now data mutations no longer come from only stores reacting to actions, so you have many "sources of truth".
The uni-directional data flow principle is as follows, very simplified for the purpose of this discussion:
Actions ----> Stores ----> Components
^ |
|___________________________|
waitFor actually does create a coupling between stores, and it leaks into the Dispatcher which has to provide the waitFor function. It's arguably one of the more contended points of the "vanilla" Flux pattern, and for example Reflux implements it differently, without a central dispatcher.
i apologise if this is a silly question however i recently have the following use case.
I have a component which I want to reuse, in one instance i want to be able to edit the data and in another instance i only want it to be viewable.
so this means in one use case i want to render say labels 1, 2 and 3 along with an edit button and in the second use case i do not want to render the edit button.
Now I am using the mvp pattern and I am currently of the understanding that logic should not appear in the presenter.
My question is: if i want to render a component based on logic from the presenter how do i do this without introducing logic in the view.
short examples are very welcome :)
Back-end > sends > the model > to > the presenter > which calls display method on > the view
Your model would be a POJO (typically a shared object retrieved from the back-end). The presenter would make and RPC call to retrieve it. Based on the model configuration the presenter will or will not call some "setAsEditable(Boolen editable)" method available on the view when receiving the model.
The view > sends events to > the presenter > which updates > the model > and sends it to > the back-end
When the user make some action on the view the presenter will receive a notice of it (through events or based on an interface) and update the model. Note the model update logic (like the display logic) is also meant to be in the presenter. The model would then be pushed back to the back-end by the presenter (via RPC). Business logic stays in the back-end.
Personal note:
Hardcore MVPers would enforce strict loose coupling between components, but it often involves writing lots of event classes and/or interfaces (some call it boilerplate). Be pragmatic. I sometimes avoid using this architecture when I know my components won't be reused, and wait until the need for reuse comes to me.
But if you can manage to stay pure, you're good !
You have a class that has to send a message to its parent. This class is not used by any other member of your application. You send the message as a NSNotification or you create a delegate protocol on that class and implement the delegate method in the parent, so you can send the message?
What is the best approach and why? There's any advantage of one method over the other?
Thanks
Notifications is useful for when you have multiple observers or objects that are interested in the notification. They're also useful for Key Value Observing.
Delegates are very useful for sending a message (which conforms to the protocol that you declare) from one object to another object designated as the delegate target.
While both approaches could be used to satisfy the described messaging requirement, a delegate protocol is the better suited choice in this case.
The benefit of notification as pattern is that many objects may respond to a notification which has been posted. An object wishing to observe notifications need only register to receive them. An advantage to this is that your code is very loosely coupled (generally a desirable value in oop). The drawback to the loose coupling in this case is the fact that you have potentially related behavior occurring across different classes and essentially all over your code base.
A delegation pattern is more tightly coupled, and your delegate object must conform to the protocol of the object it will receive messages from. Because of this, it is relatively easy to observe the nature of the interaction (or intended interaction) between the notifying object and the notified object - it's easier to grasp, simply by looking at the code, object messaging between two "related" objects. In a case where you have a child essentially announcing some behavior (which is directly related to the behavior of the parent, presumably), I think delegation is a superior approach.
Does the Zend 2 event manager have the ability to fire listeners in classes that are not loaded?
If I understand you correctly, then I believe that you can register listeners using the StaticEventManager (see Event Manager Quick Start).
In this case, you do not need to have an instance of the target class (just the name), but you can register listeners for events (typically methods) on future instances of that target class that may occur.
Of course, in order to be useful, the target class should actually compose an EventManager instance (probably via an events() method, as described on the same Quick Start page) and actually fire the events.
I confess that I am still trying to wrap my own head around the ZF2 EventManager, so if I have totally boned it up here, please feel free to correct me.
I have a GWT MVP application using Activities and Places. This is inspired by Mauro Bertapelle's sample (in this thread), apparently based on some of Thomas Broyer's work.
Here's the problem: I have LoginActivity make an RPC call, which for a successful login, returns a User. This user has a role (e.g., admin, regular user, guest). Several Views and Activities, including a NavigatorView, depend on this role for what they show or do. How do I get this User instance to the other Activities?
I do not have a ClientFactory; injection (Gin) is used for instantiating the Views in the ActivityProviders which provide my Activities/Presenters, and the ActivityProviders are injected into my ActivityMapper. So this may reduce to a Gin question: how do I get the user reference where it's needed? This seems to be similar to this SO question about global references in MVP.
Consider me a Gin newbie, this is my first attempt at using it. I'm guessing there is a "Gin way" to make this happen, but I don't know Gin well enough to know the best way to do this (if Gin should be used at all).
Much thanks.
Edit 1: Despite my best efforts searching SO for a similar question, I just found this question which is pretty much identical to mine (is the SO algorithm for finding "Related" links better than the search?). I'm thinking that the Gin answer by David is on the right track.
I don't think that an EventBus solution is possible. I'm following the Google guidelines which involve instantiating Activity at every Place change, so a single Event by itself will not suffice.
Something that I'm using on the server-side with Guice, and would work just as well on the client-side, is to bind to a custom Provider. In your case though, you'd have to make the provider a singleton and push the value into it from your RPC callback (rather than pulling it from some context).
You'd first need a specific provider:
#Singleton
public class CurrentUserProvider implements Provider<User> {
private User currentUser;
public User get() { return currentUser; }
public void setCurrentValue(User currentUser) {
this.currentUser = currentUser;
}
}
You'd bind User to the provider: bind(User.class).toProvider(CurrentUserProvider.class)
In your RPC callback you'd inject a CurrentUserProvider so you can setCurrentValue but everywhere else you'd inject Provider<User> to keep CurrentUserProvider as an implementation detail. For very short-lived objects, you could directly inject a User value rather than a Provider<User>.
If you need to notify objects of the value change, you could dispatch an event on the global event bus.
Alternately, you could always use the concrete CurrentUserProvider type (which wouldn't have to implement Provider anymore) and possibly make it a HasValueChangeHandlers so you could register listeners on it rather than on the event bus (but you'd have to clean-up after yourself in your activities' onStop and onCancel to avoid memory leaks, whereas it's taken care of automatically if you register handlers on the event bus in onStart).
(if you ask me, I'd rather go away with authenticating from within the app whenever possible)
I had similar requirements on a recent project.
When I get a reply from login (or logout) RPC I send a custom AuthenticationEvent on EventBus. All activities that are interested in this listen for this event. AuthenticationEvent has a reference to AppUser object which is null if user just logged out. AppUser contains all necessary data (privileges, groups, etc..) so that activities can inspect it and act upon it.
About global references: you can have a class with static methods providing data that you need. This class internally holds singleton references to needed instances. In my example I have static method AppUtils.getCurrentUser(). Internally it holds a reference to AppUser and also listens to AuthenticationEvent to set/reset this field.
As a side note: don't rely on client side to enforce access restrictions - you should separate your RPC servlets into two groups: public and private. Public can be accessed by anybody (this is basically login/logout RPC and some other public info RPC), while private RPC requires user to be authenticated. Access restrictions can be set per path/servlet: http://code.google.com/appengine/docs/java/config/webxml.html#Security_and_Authentication
Update:
As you noted, class with static methods is not advisable in this setup, because it is not replaceable and this prevents testing (which is the whole point of using GIN).
The solution is to inject a utility class holding globals (AppUtils) into activities that need the globals. AppUtils should be declared singleton in GIN configuration as one instance is enough for the whole app.
To use Provider or not is just a question if you want to delay the initialization of dependencies (AppUtil is dependency). Since AppUtils is a singleton for the whole app it makes no sense to have it lazy initialized.
Sometimes you will have a situation where you have multiple Activities shown on screen (in my case it was MenuBar and InfoBar). In this case, when user logs in you will need a way to notify them of the change. Use EventBus.