It costs me a bit to go back in time as these issues are already from some time back.. Let me try to give some input on these points.
2) I don't fully understand what the problem is here. Could you give an example that shows that it breaks? Anyway, let me explain a bit how my handlermanager works as I don't seem to have this problem yet... but neither do I think it solves it.... (I did this somewhere on the forum already... I think but but can't find it 123) In my implementation I can specify the source through generics as I found it important due to experience in the past. It makes it more clear and tight about what to expect in the listener event (the element of least-suprise). The steps for firing an event are almost the same, except: - I bought myself some extra freedom by introducing an extra eventbuilder object that contains the event (kind of intermediate object). The event is a stupid value object without any extra logic like the GWT event. This is takes away the need for the gwt package protected event methods btw. I moved the logica that GWT put in the gwt event in my eventbuilder, such that they al have their simple and clear responsibility. I think the current gwt event contains/does too much. I experience this when trying to extend/use it, this is difficult/not possible... The event builder will call the listener and pass in the contained event. I use the builders as flyweight object and reuse them. The event builder is passed to the fireEvent(..) method of the HandlerManager. This is an interface of which if have several sub interfaces to add extra functionality like the interceptor construction. The HandlerManager will ask the event builder to fire the event passing in the register that holds all the listeners. The event builder will then ask the register to fire the event, passing in himself. The register will retrieve all interested listeners through the type that is contained in the event builder, and will then ask the event builder to dispatch the event to the listener, passing in the listener (one by one).... I might sound a bit cumberslume.. al these forward calls (visitor pattern) (at least I think it is).. but I needed it to keep it tight and use my generics correctly... If you want allll the dirty details I really have to dig in to it again... Anyway: the above construction I needed to win extra freedom to add extra functionality like the interceptor, stop delegation, etc.. and to work with different implementations againts common interfaces (which currently isn't possible with the GWT implementation as the gwt event contains too many things: logica and data. Ofcourse this is desired looking from a rich object perspective, but you don't want to expose all the delegation to the subscribers... I mean: they can stop the delegation, but that's about it... Maybe the above will give some idea's. 3) Ok, let me give an example and hope I have some luck here... ;) I remember we had this same discussion about primitive-simple Widget interfaces, you asked me the same thing (together with Bruce), I gave some concrete interfaces.. and never heard anyting :(... My app is very simple in layout: a menu on the left and the content on the right. You can navigate to another piece of content by clicking on the next/prev button in the content screen part or by clicking in the menu. If the user navigates away from the current content screen (by clicking next/previous... or the menu), and the current shown content isn't valid, he will be asked for a confirmation. If yes, the action (=going to the new content and saving the current shown content) will be performed, if no, the action is canceled and he stays on the same content screen. I implement this through an interceptor (aynchrone in this case) that will take care of the confirmation and some other side-actions. It makes it clean and transparent. What I do roughly: I inject the interceptor in the presenter. When the select value in the model changes it will first inform the interceptor with a callback. The call back contains different methods that are called by the HandlerManager implementation to indicate success/ cancelation. In case of success (the user clicks Ok), it will inform the callback about this such that the property change can be made permanent. The handlermanager will then inform the listeners and after that call the callback to indicate that they are all informed.... If you need more details, let me know ? After describing the above, you might understand that it's desirable to open up the GWT Handlermanager to add these functionality directly to it, instead of making a copy and changing it...... Probably this is need in my case anyway... but still... Hope this helps... --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
