> class HandlerManager<Source> { ... }
Interesting how you put Generics in the HandlerManager ....
Of course this is a no go area as you explained.
Try my HandlerManager scenario like I described above; only the event
contains the actual source generics, and of course not he
HandlerManager...
Let me know if you want some code of this ? So I can grep something
together... I might need a bit of time for that... and let me know
where to send it to?
> 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?
Hmmmm... I could give some code, but I think in words the need for the
interceptor is clear:
The user selects something and the interceptor will indicate if the
selection is allowed to be committed (like a 2-phase db transaction)
or not..
Can you give me more details about what you not understand here
please?
I am afraid that the code only make it less understandable as it's
complex.. due to the asynchrone behavior.
> 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.
Hmmmm... can't remember the *precise* details anymore... it was
already some time ago... :(
One thing I remember was that I wanted to change the source in the
HandlerManager, which wasn't possible as it can only be set through
the constructor..
On Aug 7, 10:07 pm, Joel Webber <j...@google.com> wrote:
> On Fri, Aug 7, 2009 at 1:34 PM, Ed <post2edb...@hotmail.com> 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
-~----------~----~----~----~------~----~------~--~---
