Hello, I am one of few authors to blame for this throwback in the "last century" approach to the programming. I would like to offer some explanation of what I personally tried to achieve with chapters 6,7,8 and 11 - you might get better picture if you skimp them in that order.
First of all, thank you Matt for clarifying that Cairngorm is not the only solution and is not an "approved" method to solve all worlds problems. It really helps, as at this point with so many new Flex developers Cairngorm becomes what people learn INSTEAD of FLEX. A lot of veterans lately were discussing the impact of "law of leaky abstractions" (http://www.joelonsoftware.com/articles/LeakyAbstractions.html and http://www.joelonsoftware.com/articles/LordPalmerston.html) and explaining to the new programmers on what they HAVE to learn and what is optional becomes important. Second, if you do not have DB driven application that can be automated or have complex data ill suited for DataGrid, you DO NOT HAVE TO use "destination aware" option. Put in your XML dataProvider, skip 2 pages and enjoy the rest of the chapter. However, if like most of enterprise developers your data originates and ends up in relational databases, try to put chapter 6, 7 and 11 together. Now take your Cairngorm application that populates and maintains data in grid format and compare it to the approach in the book. You will notice that all your server code is generated, your commands are not needed as they are replaced with arraycollections that maintain state and demistify dataservices automation while giving you complete control. With the newer versions of daoFlex (chapters were actually written in the summer of last year) you get DataForms on the same foundation so there is solid platform for all your data aware controls. With model, commands, data beans and persistence annihilated you now have to make tough decisions. OK, I have generated code that just works by itself. Should I repackage it in Cairngorm-style framework for benefits of loose coupling? Here is the part where "believe system" kicks in. IMHO, DataGrid is loosely binded component by itself. It could care less of the beans/DTOs you are going to feed it as long as it can find the fields it needs - and when it can't, it is not going to complain either. As long as presentation objects are supporting loose coupling there is very little benefit of loosing it ;-). Here is a bonus section in the book on decoupling that most people overlook. Go to the end of chapter 8 - it talks about decoupling objects from metadata/resources. If you skipped it here is the brief version - most of the properties that constitute business values - name of lookup/key fields, lists of options, etc. If you break them into CSS analogs that would allow you to bundle certain sets together - you can indeed provide resource driven business customization the same way CSS drives look-and-feel. There is one area that is not addressed in depth in the book - primarily due to the book space and time constraints - and that is business part of the model - computed fields, validations and such. I will try to make separate posting on the subject with the workable approach that offers flexibility and very little coding - hopefully in more reasonable daytime. Sincerely, Anatole Tartakovsky --- In flexcoders@yahoogroups.com, "Matt Chotin" <[EMAIL PROTECTED]> wrote: > > RE Cairngorm, a few people have brought this up to me so I want to get > this out there. > > Cairngorm is great for many folks and many kinds of apps, and we have > obviously found success with it in Adobe Consulting (note, not the > product team). However no single tool fits all occasions and Cairngorm > certainly doesn't solve all problems. I would never recommend anyone > use Cairngorm as they're getting started with Flex, I think there are > too many concepts within the Flex framework that you need to understand > on their own before you bring in more architectures. So please make > sure you understand the Flex fundamentals before trying to learn > Cairngorm. > > Now as Tom says, for large apps Cairngorm can prove useful. But it > isn't the only way to do things and it certainly isn't the only Adobe > approved way of doing things. We don't have an "approved" method. Some > folks want us to approve something, other folks don't want us to approve > anything because they think it stifles innovation within the community. > I'm not sure where I stand on that, but for now Cairngorm is something > that Adobe Consulting uses, and that a lot of the community uses, but it > isn't the only valid approach. > > Matt > > -----Original Message----- > From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On > Behalf Of Tom Chiverton > Sent: Thursday, March 22, 2007 6:30 AM > To: flexcoders@yahoogroups.com > Subject: Re: [flexcoders] Re: Advanced DataGrid / Destination Aware > intros tight coupling? > > On Thursday 22 Mar 2007, lostinrecursion wrote: > > Thanks Tom. As I go through the book, I am seeing more and more of > > that approach. > > For the purposes of learning, taking your first few steps and building > the first few apps, it's fine. > You don't want an example of X made unclear by also doing lots of other > stuff. > > > Cairngorm isn't even so much as given a footnote in the book. > > A shame, as it's basically the Adobe approved way to build > (large/complex) Flex applications. > > -- > Tom Chiverton > Helping to heterogeneously empower mission-critical schemas > On: http://thefalken.livejournal.com > > **************************************************** > > This email is sent for and on behalf of Halliwells LLP. > > Halliwells LLP is a limited liability partnership registered in England > and Wales under registered number OC307980 whose registered office > address is at St James's Court Brown Street Manchester M2 2JF. A list > of members is available for inspection at the registered office. Any > reference to a partner in relation to Halliwells LLP means a member of > Halliwells LLP. Regulated by the Law Society. > > CONFIDENTIALITY > > This email is intended only for the use of the addressee named above and > may be confidential or legally privileged. If you are not the addressee > you must not read it and must not use any information contained in nor > copy it nor inform any person other than Halliwells LLP or the addressee > of its existence or contents. If you have received this email in error > please delete it and notify Halliwells LLP IT Department on 0870 365 > 8008. > > For more information about Halliwells LLP visit www.halliwells.com. > > > > -- > 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 >
