Cairngorm docs and confusion

Question

Hi,
I've been using Cairngorm on a large project, my first time using it.
I'm a little confused by what is happening with Cairngorm.  The only reason I used Cairngorm over the others is it's endorsed by Adobe, but it seems from my point of view Adobe has giving up on it, because I am not seeing anything change in the documentation.
An example, is I found this presentation at Max
https://share.acrobat.com/adc/adc.do?docid=bc5b2ad3-e2c4-4891-a6df-74ce010e9821
Alistair explains in the slides a lot of things that go directly against what I have read in the Cairngorm Docs.  So, apparently I'm making big mistakes by including properties in my modellocator, not using objects in the model, and not using a Presentation Layers, etc, etc.
Also, the slide show has no audio or video, so I have no way of learning more of what he is really saying.
I'm confused why the docs have not been updated to reflect the slides, and also why we can't listen to the audio/video to learn more about how we SHOULD be using Cairngorm.
Can someone please clarify on what Adobe is thinking?
Thanks a bunch.

Answer 1

I recently completed a project using the Cairngorm framework. I didn't draw the same conclusions from the documentation as you seem to have done.
The framework is supposedly providing an MVC (model-view-controller) implementation for the Flex environment. The MVC pattern is an object-oriented architectural pattern that has over time migrated or been replaced by MVP (model-view-presenter). The model in MVC was never a single object or class. It was a model built of objects. I would compare it with building a relational database model except that object-oriented models are really about behaviour and not simply data. I would expect that a model had a number of classes, collections of objects, and relationships between objects.
The model in the RIA (Rich Internet Application) can reflect the model of the underlying database (i.e. a business model) or it can reflect the requirements of the view (presentation model). In our system, we tended toward the presentation model. At least that is how I would describe it. I noticed in Alistair's presentation that he referred to different models. We did this in our design as we recognized that a particular view or collection of views had their own data requirements. A single model becomes overloaded and difficult to maintain if it contains everything in the system. It also becomes difficult to manage.
There are a couple of other things that I tried to do. I tried to ensure that the view was an MXML file with no Actionscript and was only updated through data binding. We did have a Actionscript file that was inherited by the MXML but the MXML file was not known by the Actionscript super-class. I enforced this with the view that we could test drive from the Actionscript file and consequently most of the behaviour of the system.
There is one last thing that I would say. Any design pattern / architecture is the basis for proven solutions. It will need adapted for the particular problem being solved. As such, I see the Cairngorm framework as providing a set of conventions that aid in the implementation of the MVC pattern. Those conventions will need adapted for the particular system being implemented.
I back my opinion is based on some research that I recently conducted on the perceptions of practitioners of an object-oriented program. What I would describe as expert object-oriented programmers expressed the view that I have described above. Some went further and said that they were patterns of thought that they used but that their designs may or may not accurately reflect all of the design pattern or architecture. They preferred to have the software tell them what changes are needed. Telling means that the programmer recognises the code smells and corrects them. A skill that I would admit that I haven't yet fully mastered.
I hope this helps.
Errol Thompson