Dead! (for now)
On Fri, Aug 7, 2009 at 5:10 PM, Ed <post2edb...@hotmail.com> wrote:
>
> Then I would declare it dead Bruce!
>
> With all do respect: I do very complex things with GWT and do walk on
> his boundaries...
> And to my experience.... -> I am a bit lonely out here... (yes I know
> it sounds a bit arrogant...)
> And yes, I agree that you guys have better things to do to make GWT
> first more mature before they support these complex things...
>
> Buttt... it would be nice if these things aren't forgotten and put on
> the nice-to-have list... and not on the forget-list.
>
> I think that adding (more) primitive (characteristic) widget/panel
> interfaces, like we discussed before has an higher priority, so I hope
> you guys add this to gwt 2.0. I am still suprised about the few people
> complain about this. But I have pointed out concrete clear cases that
> show the need for this...(like you asked before)
>
> Just my thoughts...
> BTW: Joe if you want some code about my HandlerManager to be able to
> define the source through generics, let me know...
>
>
> On Aug 7, 10:55 pm, Bruce Johnson <br...@google.com> wrote:
> > 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
-~----------~----~----~----~------~----~------~--~---
