A place for the Presentation Model pattern?

By all means continue to share your thought and ideas - I have enjoyed your blog posts. However, I just wanted to articulate that we have been thinking deeply on this, and this was one of the key reasons we wanted to get a Cairngorm committee in place and move Cairngorm to opensource.adobe.com, so we could engage the community earlier in our thoughts and ideas.

Steven,

Thanks for these explanations.

So, if I get it right, I guess we should wait for the docs you mention before going forward on this topic since, obviously, the opinions to be shared on Cairngorm's future are very closely related to the best practices of the current release.

David -- we've been advocating the presentation model pattern within Adobe Consulting because we're currently using it ourselves in our Cairngorm projects that are of a particular scale.

We'll be sharing our thinking more with this community in the near future -- you've obviously picked some of it up from Paul and Borre's articles, and your discussions with some of our team in Paris ?

But I do see that the presentation model is essentially a refactoring that we trend towards - it's not "the simplest thing that works" for many projects, so the refactoring series I see is:

1) Start with a ModelLocator class with very few bits of state on it
2) Extract class refactoring on ModelLocator - avoid a monolithic ModelLocator by extracting out classes representing models, and ModelLocator is a tree of models
3) Refactor towards Presentation Model pattern; this is where we want to empower our models to manage their own persisitence, particularly in data-oriented rather than service-oriented parts of our application
4) Extract class refactoring on presentation model to extract a domain model class that may be shared amongst presentation models; this is the most complex/verbose solution that we find emerges in HUGE applications that we are developing

We're not sure whether there's any infrastructure to add to Cairngorm 3, however we will be sharing this thinking and more through some technical guides that help developers understand how much complexity is appropriate in their model depending upon the scale of their application, and depending how service/data-oriented the application is ... with a well defined sequence of refactorings that can be applied as the complexity of the application emerges.