On Fri, Aug 7, 2009 at 1:34 PM, Ed <[email protected]> wrote:
>
> 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?
It's actually worse than I thought. If I add a type parameter to
HandlerManager, I get something like
class HandlerManager<Source> { ... }
But I have no way to specify the source type when it's declared in Widget:
class Widget {
HandlerManager<???> handlerManager;
}
The Source type parameter would force me to declare a separate
HandlerManager field in each subclass of Widget. But then I can't subclass a
widget and get the source type correct -- I'd need *another* handlerManager
field.
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 ?
>
To be honest, I'm having a really hard time understanding the structure
you're describing. Maybe a bit of (heavily elided) code would help clarify
it?
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...
>
If you could describe *precisely* what you think should be "opened up" in
HandlerManager, it would help me to make a reasonable judgment. As it
stands, it all seems very vague to me.
Thanks,
joel.
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
