Hi dodo, > Currently in my app all the services and action related methods are > there inside the view class itself. How can I refactor my code to > decouple action related methods in a different controller/supervisor > class?
Why would you want to do that? GWT follows (roughly) Swing/SWT programing model which is sometimes known as Model Delegate, a derivative of Model View Controller in which the Controllers and Views are merged: http://c2.com/cgi/wiki?ModelDelegate Therefore the current situation as you describe is typical. There are specific situations where it is a good idea to abstract action related code to separate controllers, and various ways to do it, but It is use case dependent. > Another aspect of my problem is that, I have created composite > widgets of my own, thus when a event is generated by an inner widget I > should get the reference of sender and since I need to perform action > on some other inner widget thus I need reference of that also. How can > I achieve this without actually taking a direct reference of each > inner widget of my composite? Again, this is a standard pattern with a Composite and makes for simpler more readable code. If (and only if) the widgets contained in the composite are invisible to the outside world (private , no public getters) then it is simplest and cleanest to have them call each other directly as necessary. For example if you have a row of tool buttons then a single ClickListener can handle their clicks and the main Composite can control behaviour most simply e.g. : public void onClick(Widget sender) { if (sender==button1) {doX();} if (sender==button2 {doY();} // where doX() and doY() are private methods of the composite } Where an event fired from such private widgets does need to be propagated to the outside world, it is common to to delegate the task to the Composite itself, for example: public void onClick(Widget sender) { if (sender==button1) { this.listeners.fireChange(this); // i.e. not the button } So the Composite provides a single view to the outside world, and the internals can talk to each other freely in the knowledge no outside class has any knowledge of them (i.e. they are fully encapsulated, and outside client classes register listeners with the Composite itself only.). There are specific classes in GWT to assist with this idea, for example DelegatingClickListenerCollection etc. I think this may be the origin of the Model Delegate pattern name. Basically it makes coding many common UI situations simpler and more readable than full MVC decomposition with no nasty side effects in most cases. Some situations benefit from full MVC decomposition. One example is a bulk data grid renderer, especially where the user can sort by column etc. Having a controller that manages and coordinates the paging/ sorting with the server data source separately from the view is probably worth it. Another is where you have several views in the UI that show different aspects of the same data model. For example a work flow process might have several views, and a step might be ticked off in any of them, but that might require an update of all the other views as well. That implies a single shared model which in turn argues for a single controller with which the views interact and listen to. regards gregor --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
