Dave, You can't have thought I'd let this slip.... ;)
> <flame bait> > Show what you have, but to me these situations are the > biggest proof where abstracted frameworks, especially around > event dispatching come back to bite you. Something simple > like clicking a button to fire a service wanders through hard > to debug framework. Why go through something as abstracted > as a FrontController/Command/Locator pattern soup to do > something as simple as fire a service from a button click. > </flame bait> When you have teams of 30-40 developers, implementing projects with 100s of different service calls, some of them RemoteObject calls, some HTTPService calls, and some of them WebService calls, when several of these service calls have an opportunity to be reused in different contexts; suddenly, the *lightweight* (let's keep in perspective that we're talking about a collaboration of 2 or 3 classes here) benefits of some common architecture start to outweigh the benefits of having people place their service calls wherever they choose in their own code. On the issue of debug; when familiar with building applications with Cairngorm, the application-level abstraction that is introduced over and above the lower-level Flex framework event model, *speeds* debugging, and doesn't in fact impinge upon it. Whenever an application fails, as the result of adding a new use-case, the debug process is quite simple and methodical: 1) Check event is registered with controller 2) Check that command is instantiated when the event fires 3) Check that execute() entry-point is called when event fires 4) Check that business delegate call is successful -- confirm that service-call happens over the wire on the server -- 5) Check that command receives the results back from the server 6) Check that the model is updated correctly Those 6 steps above ensure that the user-gesture to business logic executation and model update has happened correctly. This check is a quick 2 minute job, after which you can be sure that the problem most likely rests in your implementation of the view. I don't ever want to be painted into the position that Cairngorm is the *only* way to architect a Flex application; if you have your own infrastructure and architecture in your applications, that's fine too. But, I will defend that having a methodology behind development, having an underpinning architecture that aids collaboration, collective ownership and introduces consistency in development, is at the sacrifice of testability and debugging. We've experienced first-hands the benefits of such a microarchitecture, on a large number of Flex projects as small as 4-5 developers, and as large as 30-40 developers. I've never experienced the idea that such architecture introduce complexity ... On the contrary, simplicity is introduced where complexity otherwise exists. I share your desire to keep things as simple as possible. Cairngorm is an implementation of that desire, not a contradiction. Best wishes, Steven PS. I share (and now know who to blame ;) ) your assessment of the EJB2.0 spec. -- Steven Webster Practice Director (Rich Internet Applications) Macromedia Consulting EMEA Office: + 44 (0) 131 338 6108 Mobile: +44 (0) 7917 428 947 ------------------------ Yahoo! Groups Sponsor --------------------~--> Get fast access to your favorite Yahoo! Groups. Make Yahoo! your home page http://us.click.yahoo.com/dpRU5A/wUILAA/yQLSAA/nhFolB/TM --------------------------------------------------------------------~-> -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
