I've worked on two fairly large Flex projects at two different jobs and we had a Cairngorm callback pattern similar to UMs as well (before the UM extensions were released)
In my mind I justify it as still being fairly decoupled. The view is creating the event and stuffing in parameters anyways, so why shouldn't a callback be one of those? Sometimes the view that dispatched the event needs to know whether it faulted or succeeded to change state appropriately, and I just don't see a reason to shove that in a model somewhere. In one the projects we had a tabbed-based application where tabs could be spawned by users. I would have to have a dictionary of view states in the model or something similar, and it just seemed like it was jumping through an unnecessary hoop. It would still have been data specific to that tab instance, so it didn't seem 'wrong' to just specify a callback anytime those tabs dispatched a Cairngorm Event The command/model/delegates still have no intimate knowledge of the view, the base command class just checks to see if a callback function was specified and calls it after it finishes its other work. On Mon, Jul 14, 2008 at 9:48 PM, Josh McDonald <[EMAIL PROTECTED]> wrote: > I've been doing something similar to the UM callbacks in projects at > work, and it does tie your code a little closer to the framework than some > people like, and the "base event class" annoys a few people. It's not a > problem for us, because we're using an in-house framework (parts of which > will be OSS in the near future), but it rubs some people the wrong way. > > I'd like to know if there's any other nicer (coupling-wise) method people > are using in order to be notified of completion / failure of whatever action > a view kicks off? > > -Josh > > > > > -- > "Therefore, send not to know For whom the bell tolls. It tolls for thee." > > :: Josh 'G-Funk' McDonald > :: 0437 221 380 :: [EMAIL PROTECTED] > >
