I'm trying to pass a parameter that I have loaded on a presenter to another presenter, a car from some client, for example.
What's the best way to do this? Using the gatekeeper? Any example?
PS: I using DI with gin and the GWT-Platform framework.
If the presenter should be loaded when the event is fired you can use a ProxyEvent. Have a look at http://code.google.com/p/gwt-platform/wiki/GettingStarted?tm=6#Attaching_events_to_proxies and http://arcbees.wordpress.com/2010/08/31/using-proxyevent/.
If you want to reduce coupling, you should create a custom event, CarLoadedEvent or something. Use GWTP Plugin for that, it works great.
Then have your presenter that wants to catch that event implement CarLoadedHandler, and in its onBind() method, make it register to the eventBus :
#Override
protected void onBind() {
super.onBind();
registerHandler(getEventBus().addHandler(CarLoadedEvent.TYPE, this));
}
Finally, when a car is loaded, fire an event :
CarLoadedEvent.fire(getEventBus(), myLoadedCar);
See GWTP doc & blog:
for regular Event handling
for Event handling that should wake up another Presenter not yet initialized/showing
boilerplate code generation related to simplifying coding Event handling
Related
I'm trying to adapt my GWT web application from my home-grown MVC to GWT Platform.
I've managed to port the my application views with presenters, and essentially able to access views via PlaceRequest. And with changing the URL (#).
However I am not sure how to deal with Models using this GWT platform, in the common MVP I know there is a go() method in the presenter which fetches data, say from server via RPC.
In the GWT platform presenter here are the methods automatically generated by the Eclipse plugin:
Constructor
revealInParent
onBind
onReset
Where should I put the RPC code that will fetch and update my model. Say in the presenter I have:
ProfilePresenter.java:
public class ProfilePresenter
extends
Presenter<ProfilePresenter.MyView, ProfilePresenter.MyProxy> {
public interface MyView extends View {
HasText getFullname();
HasText getLocation();
HasText getAboutme();
HasText getLastlogin();
}
private User user; // Model which represents the User information etc.
And when the View associated with the Presenter is shown I need to fetch the User model from the server and update the model and then subsequently update the view through the interfaces it expose.
Also, say I have some buttons in the view, which then can be accessed by the presenter through HasClickHandler where should I put the event handlers?
I would put the RPC call in the onReset method.
See the presenter lifecycle
Personally I deal with events using the reversed MVP pattern. But you can also call a handler this way:
getView().getSubmitButton().addClickHandler(new ClickHandler() {
#Override
public void onClick(ClickEvent event) {
}
});
with the following signature for getSubmitButton in your view interface:
HasClickHandlers getSubmitButton()
Sydney covered most of your questions.
In general onResetmethod is a good place to make backend calls.
Sometimes when the backend call takes longer and you want to display the view only after the data was loaded you can use manual reveal.
But for the profile page I don't think that is necessary.
I also agree with the reverse MVP pattern. It's way easer to test presenters using the reverse MVP Pattern than using the HasXXXHandlers interfaces.
I am using MVVM and I would like to communicate between viewmodels. I have a user control that contains another user control inside it, and I would like the parent usercontrol to run some code when a property in the child is changed. I have seen several ways to communicate between viewmodels, such as using MVVM Light Messenger, or PRISM Event Aggregator, but I was hoping there was some way to accomplish this simply by somehow subscribing to the PropertyChanged event raised through the INotifyPropertyChanged implementation.
There is an answer by Matt Hamilton in this post but I have trouble implementing it because it needs a DependencyObject, and my ViewModels are POCOs rather than DOs
Is there some way of using the INotifyPropertyChanged system, as I would prefer to not have to implement a messaging system. If not is a messaging system the best? I also saw an example where some guy just used the code behind of the view to help pass the property, however I don't want to break the MVVM pattern as I wanna do some testing at a later stage.
There definately multiple ways to handle your scenario. One is certainly to use the INotifyPropertyChanged implementation to propogate your event. The issue is that container would need a direct reference to the child ViewModel to subscribe to the PropertyChanged event.
class ParentVM
{
private const string SomePropertyName = "SomeProperty";
public ParentVM()
{
ChildVM child = new ChildVM();
child.PropertyChanged += new System.ComponentModel.PropertyChangedEventHandler(child_PropertyChanged);
}
void child_PropertyChanged(object sender, System.ComponentModel.PropertyChangedEventArgs e)
{
if (e.PropertyName == SomePropertyName)
{
//Do something!!!
}
}
}
You could also explicitly define an event and subscribe to it.
Personally I would pass a reference of the parent viewmodel to each child viewmodel to have direct access.
I tend to avoid the MVVM Light "Messenger" as much as possible. (it's kind of useless when using IoC containers but that's another story)
I have got several Composite and I would like to add an Handler to one of them which fire an event if the user open this composite. Is there any Handler for?
Thank you
A good/easy way to fire events is by the use of the GQuery library, which emulates JQuery in GWT code.
It allows you to do things like:
$(yourWidget).blur();
to fire a blur event on yourWidget, for example... if you don't mind adding a dependency to GQuery to your project, this is the way to go in my opinion.
You can even provide a Function which will be called after the event has fired, as in:
$(yourWidget).click(new Function() {
public boolean f(Event e) {
e.preventDefault();
return false;
}
}
I am not sure how you would do that in pure GWT, but it's obviously possible... you may want to see how GQuery does that.
http://code.google.com/p/gwtquery/
I am developing painting application in which i need to save my painting.
To save i need to show save file dialog , As i am implementing MVVM pattern i can't directly use event handler.
But while implementing i thought of using PropertyChanged event directoly.
I have implemented INotifyPropertyChanged in ViewModel , I have bind all commands.
In save command in ViewModel i have called
OnPropertyChanged("Show Save Dialog"); // in ViewModel
and in code behind of user control I have added event handler as
ViewModel.PropertyChanged += new // in code behind of user control
System.ComponentModel.PropertyChangedEventHandler(ViewModel_PropertyChanged);
and in ViewModel_PropertyChanged i have
switch (e.PropertyName ) // in code behind of user control
{
case "Show Save Dialog": ShowSaveFileDialog();// this function shows dialog.
break;
}
This works fine in my situation but I don't know the dark side of this implementation.
Is it right ????
Right? There is no right or wrong, only the best choice at the current time. The only way for purists would be to abstract away the process of gaining such input from the user behind an interface, then create a View class which serves this interface and inject it somehow (IoC/DI, or perhaps by composition in the xaml if your ViewModels are instantiated that way).
Personally, I wouldn't spend too much time worrying about this, unless you must worry about this. I've done it both ways. For your average MVVM app, I think it is no great crime to just use a MessageBox, OpenFileDialog, etc. For heavily tested apps, you'll need to abstract it away. And there are other situations that demand it as well. For example, I have code that exists in an application and in a Visual Studio extension. VS has its own dialog types which should be used instead of, say, MessageBox. So abstraction is appropriate. But I wouldn't invest the work unless I had a reason to.
Why don't you just create a custom event? Something like this in your ViewModel:
public event EventHandler<EventArgs> ShowSaveDialog;
and then use
ViewModel.ShowSaveDialog += OnShowSaveDialog;
private void OnShowSaveDialog(object sender, EventArgs e){
//handle the event
}
I wouldn't just "abuse" PropertyChanged like that. There's probably nothing wrong with your implementation, it just doesn't feel right. Also, you're using magic strings, but if you have a custom event it's much more declarative, and other users of your code will immediately figure out there is a way to subscribe to this event.
If you need to pass extra information, then make a implementation of EventArgs and add the properties you need.
Well as Will said there is no right or wrong ... only best choices!
Personally, I tend more to the purist side and try to architect a system to have a clear separation of concerns ... but that's just me!
Here is an answer I gave to a post dealing with the same problem as yours. There I show the two current approaches floating around when you want to keep your view model clean of any view code.
But again, choose the way that best fits your needs/preferences!
With MVP, you normally bind the View (UI) with the Presenter in the Presenter. However with the latest version of GWT, especially with UIBinding, you can do the following in the View:
#UiHandler("loginButton")
void onAboutClicked(ClickEvent event)
{
// my login code
}
Which basically exchanges a lot of anonymous inner class code for some quick annotation code. Very nice!! The problem is that this code is in the view and not the presenter...
So I thought maybe:
#UiHandler("loginButton")
void onAboutClicked(ClickEvent event)
{
myPresenter.onAboutClicked(...);
}
But there are several problems with this approach. The most important, you blur the lines between View and Presenter. Who does which binding, in some cases it's the View, in others it's the presenter (binding to events not in your current view but that need to be attached - for example a system wide update event).
You still get the benefit of being able to unit test your presenter, but at what cost. The responsibilities are messy now. For example the binding is sometimes in the View and others times in the Presenter level. I can see the code falling into all kinds of chaos with time.
I also thought of extending the Presenter to the View, so that you could do this in the View. The problem here is that you lose the Presenter's ability to run standard unit tests! That's a major issue. That and the lines again become blurred.
So my question, does anyone have a good method of taking advantage of the annotation from UIBinding within the MVP pattern without blurring the lines and losing the advantages of the MVP pattern?
I tend to use the #UiHandler approach only when the Handler does view-specific stuff, like adding style names, etc. For other purposes (adding validation, etc), I stick with the old approach of adding the appropriate Handlers in the Presenter.
I'd recommend reading through one of the many threads on GWT Google Group about MVP and UiBinder, such as this one.
To be honest I don't use the #UiHandler annotation much, because as you said, it starts to muddy the lines between the View and the Presenter. It's totally fine to use, and a great shortcut if you don't particularly care about sticking to the pattern, though.
The presenter.onAboutClicked() route is definitely an option, but then you might as well define the handler in the presenter in the first place.
or if you are looking for a real implementation on how to make it work check out this blog post, I have to say that up until I found it everything else was still noise in my learning.
gwt 2.0.x is a great improvement on gwt 1.x but I still believe google has some way to go with their documentation and guidance since as we have seen with uibinder and mvp, it leaves a lot to the imagination on how to make things work.
hope the link shades a little bit more light on what u need.
If using the MVP pattern, your SomeView interface should have an inner Presenter interface defined which in turn in implemented by your presenter (Activity class). So inside the view do the following:
interface SomeView extends IsWidget
public interface Presenter{
...all the methods
public void doSomeAction(SomeView view);
}
...view methods
}
now in the SomeViewImpl class, attach a handler
#UiHandler("some_button")
void onClickSomeButton(ClickEvent e){
// call the presenter method (you have access to it in the ViewImpl class
presenter.doSomeAction(this);
}
It looks a bit long, but the pattern works great.
It's often useful for the view to delegate some of its actions to the presenter using a pattern sometimes referred to as a "supervising controller".
This has also been advocated by Google as a good way to benefit from the nice #UiHandler annotation at your disposal when you use !UiBinder. The main difference with the original presenter pattern is that the view keeps a link back to the presenter in order to invoke some of its methods, instead of the presenter registering callbacks towards the view.
https://github.com/ArcBees/GWTP/wiki/UiHandlers