Hi Jesse, Thanks for your response!
-- However, I still think ARP is lighter weight; I define light weight as "more files = more heavy". ARP doesn't have ViewLocators, ViewHelpers, ModalLocator, etc. -- OK, I think we should be careful here then ... conventionally, developers will talk about a heavyweight framework as one that imposes upon the application developer. A framework with less classes isn't lighterweight, it's smaller. Pedantic perhaps, but I'd be loathe to have newbies think that something is heavyweight, where in actual fact it just has a few more classes in a ZIP file. And to be honest, if we started counting marker interfaces and ArpForm classes/etc, I'd be surprised if there aren't more files in ARP than Cairngorm, and hence, by your definition, it's "more heavyweight" :) But that'd be silly :) -- My point is ViewHelper and ViewLocators; I don't see the point of abstracting that away; Commands work just fine for dealing with the deatails. I get my data from data services and stick it in ModelLocator; would I not do the same for a RemoteObject call? Get the data and hang it there for Commands to grab? -- Yes! The idea of ModelLocator is that however state is updated (client-side, local shared object, RemoteObject, WebService, HTTPService) the result of that data service is an update of state (in the ModelLocator). So the application is oblivious to the implementation of the data services, it simply binds view to model. This is absolutely our recommendation as to how you handle data that is returned, and make it available for the view. With Cairngorm 0.99, we absolutely stated that developers should use the ModelLocator strategy as much as possible over using ViewHelpers to push data onto the view (and I mean this irrespective of how you choose to implement the ViewHelper, either as a class of getters/setter, a code-behind class, etc). This allows us to advocate that the ViewHelper is now simply a class that allows us to manipulate and massage data before it is presented on the view. Perhaps data is returned in a raw or unproceesed format from a service, but we wish to clean it up in some way for presenting to the user; we'd use a ViewHelper to do this preparation of the model for the View. To put this into perspective; on a Cairngorm 0.99 architecture, we now have VERY few view helpers in our application, due to the elegance of the ModelLocator and the leveraging of data binding. But the thinning out of ViewHelpers isn't because there's something fundamnetally wrong with the strategy of keeping knowledge of the View out of commands; it's because the strategy of using data-binding for model->view notification removes many of the development problems for which the ViewHelper was proving to be an appropriate and recurring solution. ---- >>>>> So rather than a Command class have to know to do: _root.mainScreen.addressBook.addressEntry.forename.text = result.forename; The Command class could instead say: AddressBookViewHelper.setForename( result ); <<<<< See, I see no problem with that; to me, that's a Command's job, and if he can't take the heat, and needs another class to deal with extra typing... good for him. For me, I'm fine with it. ---- I think this maybe underlies another key point then Jesse ... you own the UI design and development *and* the application development. We're working on projects right now where there are 20-30 Flex developers, each of whom are collectively sharing a codebase -- it's not typical for us to be doing single-person projects. In these instances, the typical developer of a command class doesn't want or need to understand the inter-relationship of MXML files, how someone else has chosen to componetise and structure things, or built from forms or movieclips. They don't want their commands breaking when someone refactors a Repeater to a List and a Cell Renderer, and the component hierarchy changes. They simply want to say "we have data to update" and assume that the view that relies upon the data will update accordingly, irrespective of it's implementation. In the Breeze presentation that's out there where I talk about architecting Flex applications (the talk I gave at MAX last year when we announced open-sourcing Cairngorm) we defined the term "Enterprise RIA" as the tipping point for which you should consider the use of a microarchitecture like Cairngorm. I gave a number of indicators as to when you might be working on an Enteprise RIA, from memory these included: o A large number of developers working on the project o A large number of use-cases in the applications (10s or 100s) The motivation for the Command pattern is to offer scalablity in the handling of user-gestures, and to simplify the actioning of business logic in response to a number of different user gestures. So by ensuring that a keyboard shortcut, a doubleclick in a datagrid, the pressing of a toolbar button or the selection of a menu item ALL broadcast the same event, we can invoke a single command. The commands *need* not know about the view, and certainly one of our motivations in using this design pattern, is that an application developer can code the command without knowing the structure of the view. Oftentimes, the view and the command are written by different teams of developers, and increasingly (as designers become as comfortable producing MXML as they did HTML) by different skills of developers. Irrespective, if it works for you, it works for you. But as a generic architectural practice, we find when consulting that the removal of the knowledge of the implementation of the view from the commands, makes it easier for developers to join a project and become productive quickly in the collaborative development of that project (that's why we say that using the design patterns from Cairngorm will improve scalability and maintainability of the project). -- I don't recall calling it evil, but if I did, I mis-spoke. I do not understand it, cause again, my Views don't change, and if they do, I'm not nesting movieclips; I'm just calling getters and setters, and our dev cycle is short, so having to change 5 lines of code because of a simple form name change isn't a big deal; again, hard for me to see the justification in such short projects. -- Agree entirely -- in your case, it's a design/development decision that you can make, and for which you're comfortable with the implications of the trade-off. I wouldn't advocate that as a general best-practice however, for large-team large use-case developments where I'd be *really* recommending the use of a framework such as Cairngorm. Anyway - thanks for the discussion, I think it's valuable to raise these things up for people to understand. Best wishes, Steven -- Steven Webster Technical Director iteration::two This e-mail and any associated attachments transmitted with it may contain confidential information and must not be copied, or disclosed, or used by anyone other than the intended recipient(s). If you are not the intended recipient(s) please destroy this e-mail, and any copies of it, immediately. Please also note that while software systems have been used to try to ensure that this e-mail has been swept for viruses, iteration::two do not accept responsibility for any damage or loss caused in respect of any viruses transmitted by the e-mail. Please ensure your own checks are carried out before any attachments are opened. ------------------------ Yahoo! Groups Sponsor --------------------~--> <font face=arial size=-1><a href="http://us.ard.yahoo.com/SIG=12hecuf32/M=362335.6886445.7839731.1510227/D=groups/S=1705007207:TM/Y=YAHOO/EXP=1123332232/A=2894361/R=0/SIG=13jmebhbo/*http://www.networkforgood.org/topics/education/digitaldivide/?source=YAHOO&cmpgn=GRP&RTP=http://groups.yahoo.com/";>In low income neighborhoods, 84% do not own computers. At Network for Good, help bridge the Digital Divide!</a>.</font> --------------------------------------------------------------------~-> -- 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/
