There are a lot of features and schedules driving M3, this is just one. I can't make a drastic change at this point, and I can't roll the patch back, but are there a quick fixes I can make to unbreak you? Make exit() public or protected? Or can you whip up a patch?
On Tue, Aug 17, 2010 at 10:57 AM, Patrick Julien <[email protected]> wrote: > I don't know what your schedule looks like but before this patch. > This was still pretty usable and it was less expensive to track > changes in head than it was to use GWT 2.0. Now, the abstract > activities are pretty much broken. > > I understand, and take responsibility, for using GWT head, but at the > same time, what's the point of cutting M3 in this shape? > > > On Tue, Aug 17, 2010 at 1:42 PM, Ray Ryan <[email protected]> wrote: > > It doesn't yet, but it should. I think that change will not make our M3 > > release, but it should be in M4. > > BTW, because we're working on this with the Spring Roo team, we've been > > using their issue tracker. We're less likely to lose track of issues that > > are filed there, under component GWT. > > https://jira.springsource.org/browse/ROO > > > > On Tue, Aug 17, 2010 at 10:13 AM, Patrick Julien <[email protected]> > wrote: > >> > >> RequestFactory issues an event on record change but does it issue an > >> event on creation? > >> > >> On Tue, Aug 17, 2010 at 1:04 PM, Ray Ryan <[email protected]> wrote: > >> > Thanks for all the feedback. > >> > I'm definitely not suggesting that this mechanism is done, it's just a > >> > step > >> > along the way. And yes, the hard coded exit points are particularly > bad. > >> > Rather than having these activities drive the place controller > directly, > >> > I'd > >> > like them to emit events like "save worked," "user canceled," and > allow > >> > you > >> > to wire up what happens in response. Also, don't forget that the > >> > RequestFactory issues events on any record change. > >> > To that end I have thoughts about changes we can make to > HandlerManager > >> > and > >> > Widget that I think can make things a lot more flexible than what you > >> > see > >> > here, and simpler at the same time. I hope to have a design proposal > to > >> > share this week. > >> > On Tue, Aug 17, 2010 at 9:40 AM, Pascal Patry <[email protected]> > >> > wrote: > >> >> > >> >> On Tuesday, August 17, 2010 12:34:29 Patrick Julien wrote: > >> >> > Same for Abstract list, yeah, providing a default for showDetails > is > >> >> > nice, making it private is not so much > >> >> > >> >> That's right... you can always create a new SelectionModel to have > >> >> something else than showDetails() that is being called, but then you > >> >> loose about half of the whole framework usefulness... so, not that > >> >> great either. > >> >> > >> >> -- > >> >> http://groups.google.com/group/Google-Web-Toolkit-Contributors > >> > > >> > -- > >> > http://groups.google.com/group/Google-Web-Toolkit-Contributors > >> > >> -- > >> http://groups.google.com/group/Google-Web-Toolkit-Contributors > > > > -- > > http://groups.google.com/group/Google-Web-Toolkit-Contributors > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
