Synergy is still be worked on, i've gotten some outside help as my vision vs time tends to get screwd up. Its low priority as i didn't get much of an interest from folks and figured i was wasting my time? (current version is up to like 1.8.43)
I prefer cairngorm when not playing with Synergy. Scott On 8/6/05, Steven Webster <[EMAIL PROTECTED]> wrote: > 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. > > > > > > -- > 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 > > > > > > > -- Regards, Scott Barnes http://www.mossyblog.com ------------------------ Yahoo! Groups Sponsor --------------------~--> <font face=arial size=-1><a href="http://us.ard.yahoo.com/SIG=12h8mdit1/M=362131.6882499.7825260.1510227/D=groups/S=1705007207:TM/Y=YAHOO/EXP=1123336030/A=2889191/R=0/SIG=10r90krvo/*http://www.thebeehive.org ">Get Bzzzy! (real tools to help you find a job) Welcome to the Sweet Life - brought to you by One Economy</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/
