Are there lots of folks on the list that have the same sorts of feedback on
HandlerManager? I ask because, as a fly on the wall here, this conversation
doesn't sound like it's converging, and I'd like to declare this thread dead
for now so that we can move onto other things. We have a lot of other things
to be giving attention to so that we can get GWT 2.0 out. If we need to
revisit these issues in the future, we certainly can.
-- Bruce
On Fri, Aug 7, 2009 at 4:43 PM, Ed <post2edb...@hotmail.com> wrote:
>
> > 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
-~----------~----~----~----~------~----~------~--~---
