I take it you mean: http://martinfowler.com/eaaDev/SupervisingPresenter.html
I confess to having done nothing like as much as I probably should have with regard to testing GWT UI components. But I'm working on a bigger app now, so I have been thinking about it. A couple of points occurred to me: A GWT component is not a Java class, it is a javascript program manipulating the browser DOM. Much UI logic involves CSS, for example switching styles, etc so it would be hard to create a "Test Double" in the manner Fowler describes. In fact the GWT dev shell already *is* a test double in many ways. For this reason I am not sure that Supervising Controller affords the same advantages for testing in GWT as it might in Swing for example. So I am looking at a model something like this: Put components (or batches of closely related components) into separate modules (there is no overhead in either dev or production for this AFAIK). Make a test Entrypoint class in a separate module (e.g.MyComponent_test.gwt.xml) for each of these component modules so they can be individually test driven. Use the GWTTestCase Junit extension to drive the component tests via this Entrypoint. Use of Observer pattern is important to enable this, i.e. it is important that no component has any "upwards" dependencies or this becomes more difficult, e.g. you start to need "mock" versions of things. On the listeners issue: a) yes, this is why using a single listener as per I described above is efficient. b) There is definitely an overhead associated with listeners, so at a certain level of application complexity you need to worry about it. See Google's own doc: http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=google-web-toolkit-doc-1-5&t=FAQ_UIUseOneListener c) In relation to another discussion about listeners I did a quick test to see how GWT generates javascript for them. You may find it interesting, it's towards the bottom of this thread: http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/1fa4af5d2728c5ab/d693b9ac6256fde1?lnk=gst&q=gregor+clicklistener#d693b9ac6256fde1 d) I think the issue is mainly the total number of listeners of a each type (i.e. the compiled javascript has a list of ClickListeners, another list of ChangeListeners etc which need to be checked in response browser events). I think if you have, say, 10 or 20 click listeners, that's no real problem, but if you have 100 then there may be an issue with this and you may need to look at ways to get the count down. Sharing a listener between multiple widgets within a Composite is a simple way to do that which does not break encapsulation. On Feb 15, 4:55 pm, dodo <rajd...@gmail.com> wrote: > Well the purpose of separating out the action related methods from the > view is code reusability and testability without actually using the > GWT container. Thus we thought that it would be a good idea if we > follow supervising controller pattern. And we would also like to > minimize the number of listeners in our app to enhance performance. > > On Feb 14, 5:15 pm, gregor <greg.power...@googlemail.com> wrote: > > > Hi dodo, > > > > Currently in my app all the services and action related methods are > > > there inside the view class itself. How can Irefactormy 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 Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
