October 10, 2007
So What's Happening Next with Cairngorm
So with MAX 2007 Chicago behind me, and MAX 2007 Barcelona ahead, I'd like to put out some brief notes on our plans and intentions for Cairngorm.
Let's start with clearing up some uncertainties. In our Adobe Consulting Birds of a Feather, we played a few games with the audience to warm things up, including a game where 3 consultants would make a statement each on a topic, only one of which was true, and the audience had to correctly guess which one was true.
So the two lies about Cairngorm were that "we're building a lightweight version of Hibernate for AIR, and because it's lighter than hibernation, we're going to call it Slumber". That was a lie. And we also said we were going to rename "Cairngorm" to "Mount McKinley" so people would stop complaining about how to pronounce it. But that was a lie as well. So neither of these 2 things are fact :)
We've pushed the changes we pushed out as beta through to Adobe Labs, as you saw on Alistair McLeods blog. So that's now the stable version of Cairngorm for you to develop against.
I want to be very clear, in case it hasn't been - if you are continuing to build RIA with Flex and Cairngorm, and these RIA are front-ends upon Service Oriented Architectures, where you are invoking services and handling their responses - whether that be RemoteObject, WebService or HTTPService - then the current microarchitecture remains our advocated architecture for you. We have no intention of changing that in a future version of Cairngorm, so please don't hold out waiting for anything else because you think there might be big change a comin'. There's not.
However, we've been doing a LOT of deep-thinking around data oriented architectures, which are the kind of architectures that evolve as you begin to leverage LiveCycle Data Services, in particular the data management features of LCDS. Peter Martin presented a deep-dive into that current thinking - and as he preluded his presentation with, we aspire to solidifying this thinking into repeatable best-practice that we can bake back into Cairngorm. However, right now our thinking is strategy and architecture as much as it is reusable classes that we'll bake into Cairngorm. Alistair McLeod is going to give this presentation in Barcelona, and we'll be opening up discussion online as well about some of our thinking, and we look to compare our data points with many of yours before we bake this into Cairngorm. What I do see happening however, is that Cairngorm Enterprise will evolve to include best-practices for data oriented archtiectures as well as the current best-practices we advocate - and will continue to advocate - for more service oriented architectures.
Exciting stuff.
We also care a great deal about making Cairngorm developers more productive; we plan on sharing some work that we have been doing around Eclipse plug-ins to increase your productivity, but it's early days yet and we've not had the bandwidth we hoped for to drive this into the community. Hold tight, but it's coming!
If you're going to be in Barcelona, please drop by and say hi - I'll be giving my talk on Design Led Innovation again, which I really enjoyed delivering in Chicago. It's easy to get into the details of architecture and design patterns, but it's also nice to pull up to 35,000 feet from time to time, and remember that our job is to "build THINGS that PEOPLE will USE" (to paraphrase my colleague, Simon Smith, who leads Adobe Consulting's User Experience practice. I'll also be presenting in the Flex Best Practices panel.
Hope to see you in Spain...
Posted by swebster at 03:36 PM | Comments (0)
January 08, 2007
Cairngorm Code Generation
I'm increasingly questioned about how much code-generation we employ when we're developing our own solutions upon Cairngorm; let me address this point with a look to the past, the present, and the future.
The Past - From UML to Code Generation for the Mother of Cairngorm
Way back in the past (1999-2000 timeframe) I was a huge advocate of UML and roundtrip engineering; in fact some of my now Adobe Consulting colleagues were colleagues in a past-life, where we were ardent users of the Together UML tool for Java. Together were acquired by Borland, and Together UML now ships with Borland IDEs I believe.
Around the same time I began to sip from the agile firehose, I became less interested in UML modelling and model-driven development techniques. It was around this same time that I first was exposed to the Core J2EE Design Patterns from the Java One presentations by Alur, Crupi and Malks, and developed my first architectural framework using these patterns in Java. We called the framework "Mesh" (as in a wireframe mesh for the application, remember this was before struts, but same idea) and found ourselves laboriously writing lots and lots of repetitive "handle-turning" code. Mesh was the mother of Cairngorm I guess, in that Cairngorm took a subset of the design patterns that we leveraged in the Java world. In Cairngorm, we discarded the Data Access Object (DAO) pattern, the Business Delegate became a much simpler facade onto server-calls, as opposed to an almost object-to-relational bridge between the Java value-object world and the JDBC PreparedStatement and ResultSet world for Create, Read, Update and Delete methods. And of course, the value objects mapped very closely to the underlying database structure, as the DAO pattern adapted tables to objects.
We found that any story (feature/use-case) we picked up for development would inevitably be a bottom-up development of "add/augment a database table, update the value object definition, create a new DAO if it was a new table or view on the database, or tediously update lots of SQL queries and iteration over ResultSets if we were simply adding columns to a table, write new methods on the DAO, and then write new methods on the appropriate Business Delegate class to call the new DAO methods, adapting ResultSets into value objects and value object graphs. Only then would the story-specific fun begin, as we implemented Command classes and JSP to render the view. Boring, boring, boring.
With all this tedium, I turned to code generation of the value objects by JDBC introspection of the database metadata (creating value objects per table, and attributes on value objects according to columns in the table). I'd then code generate the DAO classes, all the CRUD operations and queries, and the business delegate methods for each DAO method. It was all very crude (perl initially, Java eventually) code generation, and inevitably we'd step in and do some hand-coding or optimisations to the code anyway, which meant we then didn't want to rerun the codegen (it wasn't as clever as being round-trip code generation).
I'd argue that with all this tedious VO, DAO and Business Delegates upon a database tier, the effort for code-generation just about paid off for us.
If you're interested in this kind of approach, from database through Java-tier all the way to creating client-side code (not Cairngorm based) and a view, the team at Farata Systems have created DAOFlex that will do exactly this kind of code generation, much more elegantly than my home-brew approach at the time as well There's an article on Adobe devnet that will get you started.
The Present - Adobe Consulting on Cairngorm Code Generation
Right now, I'd say that the amount of code that we would typically usefully generate hasn't really justified the effort; code-generation is a decision that a technical architect will make on a project by project basis, but it certainly isn't in our arsenal of practice-wide techniques that we apply to each and every project.
Peter Martin did make some attempts with the XDoclet 2 work that he did, building on some work by Joe Berkowitz of Allurent. As you can see from his blog entry, it was a lot of work to create value objects only, which in the grand scheme of our typical projects, don't account for a whole host of development effort and time to maintain.
So in summary; right now we're not employing a great-deal of code generation and don't feel that we're suffering in productivity because of it. Those coming from a Ruby on Rails background are often impressed at the ability to automagically generate so much scaffolding for CRUD type applications - I think the DAOFlex approach may work for you here, and remember we're never necessarily advocating Cairngorm for your simpler Flex applications anyway. Someone asked me in blog comments recently whether Cairngorm and Flex could be more complex than Ruby on Rails with AJAX, and I guess sometimes it can be. However, those are two poles of a spectrum, and in-between there are a number of much-simpler non-Cairngorm Flex approaches that can be taken to rapidly deliver simple applications. There are times when i think you shouldn't use Cairngorm.
I guess under the present tense, I would like tomention the work that has been done by Eric Feminella in a project he has called Cairngen. Eric's motivation is to remove the repetition associated with creating Events to be registered with the Front Controller and their corresponding Command classes, by creating the notion of a "sequence" that can code generate stub classes for the Event and Command. Cairngen will also make it quicker for you to start a brand new Cairngorm Flex project, by creating all the project structure, folders and template classes for a skeleton Cairngorm project. Cairngen is a server-based solution, leveraging PHP and AMFPHP to manage the code generation from templates - it may work for your workflow, and is definitely worth checking out on Eric's blog.
Though I've never used the product, I noted that WebOrb is now also generating Cairngorm code from templates as well, so that may be worth checking out if you're using WebOrb already.
The Future - Integrating Cairngorm more tightly into Flex Builder workflow
I spoke in my last blog entry, that our Adobe Consulting team are constantly balancing client and project committments, with practice and community committments to deliver best-practices, guidance and productivity tools for those using the same tools and technologies that we do every day.
As we focus on Cairngorm 3, we're also very focussed on enhancing the workflow for Flex developers who are working within FlexBuilder. We've a number of ideas that are more than simply push-button Code Generation that will yield the flexibilities and benefits that we consider from working with a Cairngorm architecture, and that will furthermore leverage the consistency and predictability of Cairngorm Flex development to assist developers in building applications with Cairngorm and Flex. That was a hell of a long sentence. It's still very early days in our development, so we have nothing to preview or share at present ... but hopefully that gives a little insight into where we're going in terms of developer productivity around Cairngorm. I'm sure the consultants who have this work as their practice targets will release more information, or even previews, as and when they have something ready to share.
If I've missed any other code-generation or general Cairngorm productivity tools in my roundup, please feel free to add them here in the comments.
But hopefully that shares the current working practices within Adobe Consulting, and gives you some confidence in your own approaches.
Posted by swebster at 11:40 PM | Comments (12) | TrackBack
September 10, 2006
Cairngorm Community Documentation and eLearning Project
I'm really pleased with the following piece of news; Evan Gifford, one of the members of the highly popular flexcoders mailing list discussed with me his hopes to create a community around Cairngorm documentation and eLearning project.
Evan has created a new YahooGroup cairngorm-documentation, which is to be the focus of a community-driven documentation effort for Cairngorm.
Those of you on the flexcoders mailing list have seen Evan work with the community to create some diagrams that help newcomers to Cairngorm better understand how the patterns work together; Evan's vision is to extend this to interactive eLearning modules and tutorials that will aid developers in quickly understanding Cairngorm, and the best-practices around Cairngorm.
I think this is a great step forward; please consider signing up to Evan's list if you'd like to steer the direction of this initiative, or if you'd like to support Evan by contributing to the initiative.
Posted by swebster at 09:18 AM | Comments (1)
August 21, 2006
Why I think you shouldn’t use Cairngorm
I know what you must be thinking – Steven Webster is suggesting I shouldn’t use Cairngorm ? Well no, not exactly. However, the rapid adoption of the Flex 2 platform that we are currently enjoying has seen us enjoy a tremendous number of new developers to the Flex platform, many of whom are trying to absorb as much information they can in as short a time as possible. When you first become aware of the tremendous opportunities for solution development with Flex, it’s no surprise that you want to ascend the adoption curve as quickly as possible. However, there’s no short-cut to experience, and that’s the topic I want to call out here. If you’re new to Flex 2 or Cairngorm, then I’d love for you to read on a little…
So let me try and highlight some of the reasons I think you shouldn’t use Cairngorm. If this is you, I’m simply asking that you put a little space between where you were before you downloaded Flex, and where you will get to with Flex before you start building applications. That space is where all the invaluable lessons will be learned, that will serve you well in the very near future.
REASON ONE: I’ve never built an RIA of my own without Cairngorm. Not even a mini-one.
I guess this signifies your place on the learning curve; most first-time Flex developers will typically try and learn their way through the framework by building a number of small applications that test their understanding of Flex concepts.
So you’ll perhaps build some applications that just create a user-interface with containers and controls. Then you’ll maybe see if you can create a dynamic user-interface, by calling a web-service, an HTTP service or maybe even some Java business logic you have, and see if you can bind those results (you’re learning data-binding now) to a Data Grid, or other such component.
You might then try and make your application able to update some back-end persistence tier; so now you’re going to write a Java class, or a CFC in Coldfusion, or some PHP using AMFPHP, or maybe even just expose some C# code as a web-service, and see if you can’t invoke some of that server-side business logic to create, update or delete something in a database.
This is a milestone Flex accomplishment.
Next, you’re probably going to write some applications that test your understanding of styling, of states, of effects, and all manner of other Flex features – learning how to write inline ActionScript in an MXML class and invoke those inline methods in click-handlers, or upon creationComplete. You’ll then start extracting some of that ActionScript that’s inline into external classes, and flipping seamlessly between the world of MXML and ActionScript.
You don’t need Cairngorm for any of these applications you’re building above. And more importantly, if the experience of building these kind of applications isn’t one that you share, then you’d be a number of standard deviations to the left of the majority who are building applications with Cairngorm.
So go and build some sample applications, and just get used to working with Flex. Once you’ve done that, go and read the 6-part article series, and see how many of the challenges we discuss, resonate with you in your own development.
REASON TWO: You’ve seen an application built in Flex 2 and Cairngorm 2, and you want to use that as the starting point for your application. Even though REASON ONE above still applies.
The aim of the sample applications that we have released built upon Cairngorm, is to exemplify some of the best-practices when building Cairngorm applications, or to give people something they can pick apart to better understand Cairngorm.
However, these applications are not intended as the starting point for your applications – there are very few customers out there who only have 16 products that they wish to sell, and are therefore candidates for a quick rebrand of Cairngorm Store !
When you’re ready for Cairngorm, I’m going to ask that you take your first step with the Cairngorm challenge at the end of this blog entry. If you complete the Cairngorm challenge, then you’re ready to build more complicated applications with Cairngorm. If you can’t complete the Cairngorm challenge; take a few steps back and re-assess where you are in your Flex learning. Cairngorm will still be there when you’re done.
REASON THREE: Your application has only one or two user-gestures to react to.
So what exactly do I mean here ? I’m trying to measure the complexity of your application – how many different things can the user do with your application, that merit some computation being performed on the client or server. Viewing all products in a catalogue is a use-case. Adding a product to a basket is a use-case. Deleting a product from a basket is another use-case. Taking the basket to the checkout is another use-case. Checking out is another use-case. Ad infinitum. If your application has several use-cases, then the organisation that Cairngorm will bring to your source-code becomes valuable.
If however your application has one or two different views, and a few buttons/gestures that the user can make – then you can probably accomplish the application you are building without Cairngorm. Remember – the team behind Cairngorm are also huge advocates of agile software development, and the doctrines of simplicity that pervade agile thinking. Sometimes the simplest thing that could possibly work, is not to use Cairngorm. Or to paraphrase someone smarter than me, “…the best solution is not when there is nothing left to add, but when there is nothing left to take away…”.
REASON FOUR: You are the only person developing your RIA. Ever.
Many of the benefits we advocate from Cairngorm are from the predictablility, maintainability and scalability of the code-base, when it is organised with “Cairngorm thinking”. It becomes much much easier for developer D to contribute to a codebase that developers A, B and C have been working on, and to contribute to the codebase without making it more brittle to change. Or to quote another agile ambition – it can enable the idea of “collective code ownership”.
If you are the only person working on your application, that’s a good time to take a sanity check on whether Cairngorm is necessary. REASON THREE is important here – if you are the sole developer on an RIA that will have 20-30 use-cases, yes, you’ll benefit in the long term from Cairngorm. But at least use this sole-developer case as a sanity check.
REASON FIVE: You’ve found a bug in Cairngorm.
If you find a bug in Cairngorm, there’s a really good chance it’s too early for you to be using it in mission critical projects. I state this with confidence, because many years ago I was a C developer who kept finding bugs in Kernighan and Ritchie’s C compiler. Every day, I’d find something wrong with the compiler – in fact, come to think of it, I think I was responsible for finding some real clangers in the Pascal compiler on SunOS as well, back in the day.
Well, I say bugs … more often than not (in fact, come to think of it I don’t think I’ve ever successfully filed a bug against a compiler) they turned out not to be bugs. But they almost were … had it not been for the mistake that *I* had made! In fairness, I think Ali found a bug in the Java compiler once, but then he also refused to allow iteration::two to accept a tax refund from Inland Revenue, because he found a flaw in their calculations when we were subjected to a routine VAT inspection. It takes a special kind of pedant to find bugs in compilers, and flaws in Inland Revenue VAT calculations. Hope that this isn’t you.
Seriously; I don’t want to suggest there haven’t been bugs in Cairngorm, and when we’ve been through early betas, like any other software products, we’ve allowed the occasional bug to slip through. However, the Cairngorm releases that we make publically available, compiled as SWCs … we use those a lot. We eat our own dogfood. There are a lot of folks in the community using them, and if you can’t get the basic login sample that we ship to work then I’ll hazard a guess that it’s a flaw in your system setup, not a bug in Cairngorm.
If you’re getting frustrated that you’ve found a bug in Cairngorm, and you don’t know what the error message means – there’s a pretty good chance that a little bit more time spent up at REASON ONE, writing some more sample applications and experiencing compiler errors while you take your baby-steps, will help you steam past the configuration problems you’re probably experiencing with your particular Cairngorm sample application.
CAIRNGORM CHALLENGE
So here’s the Cairngorm challenge. The rite of passage for Flex developers everywhere. Open Flex Builder, and create a new Flex project. Import the cairngorm SWC – that’s right, not the source code, import the SWC.
Now, write yourself a simple Cairngorm application, that displays a datagrid, calls a publically available web-service somewhere, and then renders the results in the data grid.
Here’s a clue – you’re going to register one event with the controller, you’re going to write one command class to get the results, and to update the model locator when the results come in, you’re going to create a business delegate class for your command to invoke the web service with, and you’re going to register the web service with the service locator.
Now this is way overkill for calling a webservice to populate a data grid. But if you’re ready for working with Cairngorm, the above will be HelloWorld.cpp to you (and there will be no bugs to find in the compiler)
I GET IT. I THINK I’M READY FOR CAIRNGORM.
Fantastic. First of all, it’s fantastic, because if you are here, then you’ve wrapped your head around Flex 2, you’re comfortable building little sample applications that leverage all the various features of Flex, you understand the various problems that Cairngorm is addressing – because you read about them in my 6-part article series on Devnet, and because what’s more, you’ve actually encountered or at least became self-aware of the problems that we cite as the forces for the patterns we chose for Cairngorm. Isn’t it great – that patterns are solutions to recurring problems, and you’ve actually experienced the problems first hand ? It gives you a certain empathy with the solution already.
Now that you’re ready for Cairngorm, www.adobe.com/go/cairngorm will continue to evolve with everything that you need to build scalable, maintainable, mission-critical bet-the-business applications upon Flex 2, with a little bit of our thoughts on best-practice architecture baked in.
I’ve been deliberately tongue-in-cheek in this blog-entry, but I’m motivated by a serious point; increasingly, we’re finding developers who are finding Flex 2, and within a heartbeat are then finding Cairngorm. If developers jump too quickly into Cairngorm, it can introduce frustration into a learning curve that should have been much more shallow, and much more enjoyable, and much more focussed on Flex 2.
“But we’re a strategic customer, who are betting the business on Flex 2 and we need to ensure that we’re delivering with best-practices. And we need to be live in 3 months”.
Then that’s where leadership and mentoring are infinitely more important than technology and architecture – and organisations such as Adobe Consulting can help assure you that success.
In the meantime; there’s a great deal of people like you hanging out on Flexcoders, and a greater number of people who have taken this road ahead of you, and are more than willing to give you the help you want. So find us over at www.flexcoders.org if there’s anything we can do to help.
Don’t run before you can walk. Ain’t it always the way.
Posted by swebster at 01:38 PM | Comments (26)
Cairngorm Documentation - Tell us what you want
Dan Harfleet has posted over on his blog about our current efforts within Adobe Consulting to revisit the content on Adobe Labs related to Cairngorm.
We're now devoting some time and effort to increasing the level, depth and breadth of content that will help you be successful with Cairngorm - Dan is soliciting feedback from the community for what would best help them get started, and get productive with Cairngorm. So what do you need; more sample applications ? More getting started articles ? Deeper-dive articles into specific topics ?
Please check out Dan's blog, leave him some comments or drop him a line, and we'll be able to focus the time we spend on this to meet your needs more exactly.
Posted by swebster at 01:32 PM | Comments (3)
August 10, 2006
Developing Cairngorm 2 and Flex 2 Applications Document
Digimmersion are a company that create stencils for Visio for creating wireframes for Flex development; I notice that they have a great little document that explains to people how to build a Flex 2 application with Cairngorm - you can find it here. For those of you learning to develop with Cairngorm, you may find value from this 30-page article.
It's really satisfying to see that the community is now delivering these offerings around Cairngorm and Flex !
Posted by swebster at 06:16 PM | Comments (1)
June 28, 2006
Go Cairngorm!
There's now a new easy-to-remember URL for Cairngorm, which we'll adopt as the URL we'll use in any communications/emails. You can now send people to http://www.adobe.com/go/cairngorm. Thanks to the Adobe web-team for arranging this for us, despite the myriad of other changes they've had to do for the Flex Release today!
Posted by swebster at 07:06 AM | Comments (1)
Cairngorm 2 (for Flex 2)- Now Available on Adobe Labs !
I'm hugely excited that Cairngorm 2 is now available for download from Adobe Labs, complete with a new home at http://labs.adobe.com/wiki/index.php/Cairn gorm
A number of the Adobe Consulting team have contributed greatly to the Cairngorm 2 project, either directly (by working on getting this packaged for distribution on labs) or indirectly by working with the technology day-in and day-out on customer engagements. I'm sure the team will have their own thoughts and blog entries to share with you in the days and weeks ahead, and look forward to their contributions.
More importantly, I'm deeply excited by the infrastructure of Adobe Labs as an enabling technology by which the community can now become pivotal in contribution. We've put in place a framework structure on Adobe Labs, that we'll monitor and grow over time to embrace the work that the community has done around our offering. We'll be looking to the community to share ownership in the documentation around Cairngorm, the sample examples around Cairngorm, as well as the links to resources that you find useful in getting started with Cairngorm.
The Adobe Consulting team will be using Labs as a place where we can continue to offer insight from the field, and advocate our thoughts on using Cairngorm across the entire Engagement Platform - be that working with Flex Data Services, or using Cairngorm in a Flash Lite or Apollo environment. These are all things we have consultants wrestling and working with right now, and all goodness that we'll be sharing in the months ahead. Your comments and suggestions are now welcome.
,p> Many of the Adobe Consulting team are offsite in Dublin right now, and we have limited access to our email/blogs for the rest of this week, so forgive us if we don't respond to your questions or comments as quickly as we usually do. I expect however, that the rest of the team back home will step up as appropriate.There are some changes to Cairngorm 2 from the last beta that we released, that incorporate the community feedback and field-insight that we have received. There's a brief discussion in the release notes for now, with more information to follow through our blogs, and through further refinement of the Wiki content. We had committed to ensuring that Cairngorm 2 was available for you in concert with the Flex 2 release, and that's the promise we've been focussed on keeping for you.
Download it, take it for a spin, and as always, let us know what tremendous user-experiences you're delivering upon Cairngorm 2 and Flex 2 !
It's a hugely exciting time in our community !
Posted by swebster at 12:15 AM | Comments (2)
June 13, 2006
Cairngorm 2 - Coming soon to Adobe Labs!
Many of you have been asking us publically and privately for latest builds of Cairngorm, and of updates to Cairngormstore, and we've been a bit quiet as to the progress we were making....breaking the silence, I'm now pleased to be able to tell you in a public forum that our behind-the-scenes efforts have been instead focussed on getting Cairngorm approved and ready for a forthcoming release on Adobe Labs.
Almost since the day we became Macromedia Consulting (and then Adobe Consulting), we've been working with the various internal teams at Adobe, from the Flex product team, through to our consulting teams, legal, finance, and all manner of other stakeholders to ensure that we could find a new permanent home for Cairngorm on Adobe Labs.
Don't ask me dates, as we can't reveal anything concrete. Aiming for first half of the year...
What this means for Cairngorm developers everywhere, is that we'll have a top-level project on Adobe Labs, with a Wiki offering an ever-increasing amount of documentation, samples, links to Cairngorm articles, as well as the very latest builds of Cairngorm 2 itself. Many of you have been building your own sample applications with Cairngorm, creating your own documentation, diagrams and tutorials, and we'll have an environment where we can now make these more readily accessible to the wider community.
In the coming days, I'll blog a little more about some of the changes we've made to the final release of Cairngorm 2 that you'll receive shortly. And relax -- any migration efforts on your part, if you've been with us this far, will be minimal. We have taken on-board the feedback the community has been giving us, along with our own field-level experience from our consulting teams, who have been busily developing Flex 2 applications upon Cairngorm 2, on behalf of a number of Adobe Consulting customers.
I trust this news signifies the continuing and increasing committment that we're making to Cairngorm, and our continuing ambition within Adobe Consulting to make our internal best-practices instantly and freely available to the current and future RIA development community.
Posted by swebster at 10:45 PM | Comments (3)
June 01, 2006
Kiwi and Cairngorm Code Walkthrough
Brian Riggs of the Adobe Kiwi team has posted a fantastic blog entry regarding how the Flex 2 NoteTag application has been built upon the Cairngorm microarchitecture.
Taking a single use-case in the application - selecting one Note from a list of Notes - Brian walks through the sequence and employment of the various design patterns, and shows how the application is delivered with "Cairngorm Thinking". For many people, the concept of design patterns are an abstract and confusing one, until they are applied in some meaningful context - Brians example is complete with some diagrams that neatly describe how Cairngorm fits in with MVC thinking.
Posted by swebster at 01:16 PM | Comments (0)
May 26, 2006
Kiwi on Adobe Labs (Cairngorm Inside)
So NoteTag is the first part of the Kiwi project that just graduated to Adobe Labs, from one of our teams who are currently exploring how Flex and the wider Adobe Engagement Plaform can be leveraged in the world of the Read/Write Web.
I had a walkthrough of NoteTag - a Flex 2 application - some time back by the team themselves, and it's an interesting concept in its own right - this particular application (which is one of many the team are working on as part of the Kiwi initiative) is an application that allows you to take notes during meetings, and assign tasks from these meetings to other individuals.
NoteTag exemplifies some of the ideas that Kiwi team are exploring, and making available through some Kiwi Project libraries. Notes themselves are stored as blog entries, tasks are formatted using a microformat, and tags are used to connect tasks to individuals. The source code - which you can download - includes a library for the AtomProtocol, a TagServerProtocol, an enhanced library for RSS that supports setting data in an RSS feed and a connections library for managing connections to Web Services.
One of the ways I became aware of the NoteTag project, was because the development team chose to build their Flex 2 application upon the latest build of Cairngorm. It's great to see some of our own internal projects that are built upon Cairngorm are making it out into Labs - we really are "eating our own dog food".
For those of you that want to take a look at how to build applications upon Cairngorm, why not download the source for NoteTag, and see how the Kiwi team interpreted the microarchitecture, and used it as the foundation for their project ?
The Kiwi team have their own blog going on, and there's a screencast of NoteTag in action if you're interested.
Posted by swebster at 12:28 PM | Comments (1)
May 09, 2006
Cairngorm 2 (for Beta 3) now has Stateless Commands
We just realised that the build of Cairngorm 2 that we just put out, actually sneaks the "stateless commands" that we've been using ourselves for quite some time now. This is going to require the tiniest amount of change to your Cairngorm applications in a single place - your concrete front controller - and you should understand what benefits we felt motivated this change.
Typically, in your own Front Controller in Cairngorm applications, you would have a bunch of lines of code such as:
addCommand( MyController.EVENT_LOGIN, new LoginCommand() ); addCommand( MyController.EVENT_LOGOUT, new LogoutCommand() );
We're now going to ask you to change those lines of code to:
addCommand( MyController.EVENT_LOGIN, LoginCommand ); addCommand( MyController.EVENT_LOGOUT, LogoutCommand );
Since the change is so subtle, let me emphasise - the addCommand() method is now accepting a String with the *name* of the command, rather than a new instance of the command - new LoginCommand() - in its argument list.
What this means, is that each time a command has its execute() method invoked by the controller, this execute() occurs on a new instance of the Command class every time. The handlers (results and faults) are still of course invoked on the instance of the Command that was "executed".
Until now, Cairngorm has always executed on the same instance of the command - something that we wished had never made it into our first release, but once it was out there, we were wary of making the changes.
You should be aware that if your application is relying upon a side-effect between invocations of the Command, then this side-effect will no longer exist between command invocations. So - no state is held in a command between invocations, and if you need to retain state, your strategy should be to explicitly capture that state and hold it in the ModelLocator.
This is still a beta release of Cairngorm, so we're open to suggestions from the community as to this change. However, it's a practice we've been employing for several projects now, and one we'd certainly advocate to our own clients.
Let us know how you get on with this - it's certainly a relief for us that this is finally part of the public build of Cairngorm.
Posted by swebster at 01:33 PM | Comments (12) | TrackBack
Cairngorm 2 for Flex 2 Beta 3
Hot on the back of the public release of Flex 2 Beta 3, here's an updated patch of Cairngorm 2 for you, that will allow you to migrate your Cairngorm 2 applications to the new Beta 3 platform.
There is very little change here from the previous version of Cairngorm; certainly the APIs and classes are stable with the last version, and this should be a drop-in replacement for you.
The ZIP file is ready to drop into Flex Builder 2 as a library project - Peter Martin is going to blog separately about how you can import Cairngorm as a library project into Flex Builder 2, alternatively however you can just drop the SWC into your projects, or include the Cairngorm classes directly.
Between now and the launch of Flex 2, we'll have some new bits to deliver you in Cairngorm that will reflect the innovations Adobe Consulting in EMEA have been making on the Cairngorm codebase in a large number of past and present solution deliveries. I'll blog more details of those in the near future.
Coming soon ... an updated version of Cairngorm Store for Beta 3 as well....
Posted by swebster at 01:07 PM | Comments (6) | TrackBack
May 02, 2006
Tell us your Cairngorm Stories...
Robin Hilliard of Rocketboots posted today about an application that he has developed with Flex and Cairngorm, that has over 1700 classes, and around 500 MXML files. The application has been built by a project team, and for a client, who have attributed the successful delivery of the project to Cairngorm (and I'm sure to the development skills and hard-work of the team as well !).
This is very much a recurring theme; to hear about development teams who have embraced large mission-critical applications and with hindsight, have said that they'd have no idea how they'd have achieved what they've achieved, had they not embraced Cairngorm.
Even more gratifying, is to see a number of job-postings appear, with organisations such as Yahoo!, who not only ask for experience of Flex, but experience of Flex with Cairngorm.
Now that I have a blog that does an admirable job against comment spam, I'd like to open up this blog-entry to ask if people would like to share their experiences of commercial or large-scale applications that they are developing with Cairngorm. If you can share names and URLs all the better, but even just sharing your experiences would be great feedback for us !
Posted by swebster at 04:21 PM | Comments (2)
February 01, 2006
What's new and changed in Cairngorm 2.0 alpha
Let's review some of the fundamental changes that have taken place in the current alpha of Cairngorm 2.0, both from an internal point of view (how we've reimplemented some of the API under the covers) and some of the public API changes we've been compelled to make. We'll then talk about some of the future changes we're thinking of making, and soliciting feedback on.
Change to the ModelLocator API
The implementation of Data Binding has changed significantly in Flex 2.0; in terms of migrating code that leverages data-binding, it's now necessary for us to explicitly mark classes, methods or attributes to which we wish to data-bind, using the [Bindable] metadata. Additionally, it's no longer possible to bind to static attributes in a class - which was the "simplest thing that could possibly work" that we'd elected in our implementation of our ModelLocator pattern we introduced to Cairngorm 0.99.
The ModelLocator is therefore now implemented as a true singleton; we provide a getInstance() method on the ModelLocator, and then hold public attributes for our model on that instance. By marking the ModelLocator class as [Bindable] we can now bind to the ModelLocator using this notation:
<mx:Text text="{ ModelLocator.getInstance().statusMessage }" />
This is actually back towards the implementation we almost released for Cairngorm 0.99; furthermore, this should be a simple search-and-replace migration once you've udpated your ModelLocator implementation. We provide an example ModelLocator implementation in org/nevis/cairngorm/samples/login/model/ModelLocator.as
Value Objects
Since Value Objects are often used in bindings, we're advocating the following best-practice of always marking your value objects as [Bindable] as follows:
package org.nevis.cairngorm.samples.login.vo
{
import org.nevis.cairngorm.vo.ValueObject;
[Bindable]
public class LoginVO implements ValueObject
{
public var username : String;
public var password : String;
public var loginDate : Date;
}
}
You'll also note that we implement the ValueObject marker interface; some developers like marker interfaces, some don't, and we've provided one and will leave you all to make your own decisions about your own preferred best-practice.
EventDispatching leverages the Flash Player 8 Event Model
In Cairngorm 0.99, we differentiated Cairngorm Events (events that are the result,typically, of a user-gesture) by broadcasting them via our own EventDispatcher class. Your typical dispatch of a Cairngorm event was to use code in the form EventDispatcher.getInstance().broadcastEvent( ... ).
Under the covers, Flash Player 8 now handles events natively - and we were circumventing all this goodness by using our own EventBroadcasting mechanism. With an eye on performance, and to simplify understanding, we've decided to embrace the underlying Flash Player event model, and to deprecate the use of the Cairngorm EventBroadcaster class to instead use the built-in dispatchEvent() notation. In fact, in the alpha build we give you, we've taken out the EventBroadcaster altogether - to be decided is whether we put that back in, but clearly mark it as deprecated. Your thoughts welcomed.
However, we're keen to differentiate CairngormEvents - you'll find a new CairngormEvent class in the org.nevis.cairngorm.control package. A CairngormEvent is a base-event class that we advocate developers extend, to create application-specific Cairngorm events, such as LoginEvent, LogoutEvent, etc. CairngormEvent will bubble it's events (ensuring that they reach the controller) and does not allow events to be cancelled - if you sneak under the covers of CairngormEvent you'll see how we use the default properties of AS3.0 method parameters to set these for you.
Again, take a look at the sample application to see how we use CairngormEvents; class LoginEvent extends CairngormEvent, and holds a single property - a value object with the user's login details. The login view (Login.mxml) creates and dispatches this event into the system as follows:
public function loginUser()
{
var loginVO : LoginVO = new LoginVO();
loginVO.username = username.text;
loginVO.password = password.text;
var event : LoginEvent = new LoginEvent( loginVO );
dispatchEvent( event );
}
Now, there's no need for you to interrogate event.data.* when you want to handle Cairngorm events, as you'll see in LoginCommand:
var loginEvent : LoginEvent = LoginEvent( event ); delegate.login( loginEvent.loginVO );
Instead, you can fetch your data directly from the event attribute, eg loginEvent.loginVO. If you really want to be lazy about this, and dynamically attach data to a data property, we've used the new * type in ActionScript 3.0 to add the following to a default CairngormEvent:
/** * The data property can be used to hold information to be passed with the event * in cases where the developer does not want to extend the CairngormEvent class. * However, it is recommended that specific classes are created for each type * of event to be dispatched. */ public var data : *;
So if you want to skirt our advocated best-practice, we've given you the hooks to do so; in seriousness though, this should hopefully aid with your migration.
So that's the other key migration to Cairngorm 2.0 for you .. migrate your event broadcasting to use dispatchEvent() and CairngormEvent subclasses where possible.
Change Method Signature on Commands
To accomodate the new CairngormEvents, we've changed the signature of the execute() of the Command interface to take a CairngormEvent; this reflects underlying changes in the FrontController implementation, which you needn't be concerned about to just use Cairngorm.
What lies ahead ?
This is an alpha, so first and foremost, we release this for community feedback. There are a significant number of large Flex applications built upon Cairngorm, and your experience migrating them to Cairngorm 2.0 is of interest to us. Let us know how you get on with the build we've released, and you can steer our next build.
In Cairngorm 0.95, for historical reasons we have to scratch the insides of our heads to remember, Commands are stateful. We don't like this, we've had to work around it on projects of our own, BUT, we have a responsibility to not make changes to Cairngorm that could impact upon all your developments. So if you're relying upon the statefulness as a side-effect, then be warned that in a future Cairngorm 2.0 alpha we're going to make Commands truly stateless - as they should be - so that they don't persist data between invocations. If you require state to be maintained between executions, you'll have to manage that explicitly - as you should have been doing anyway !
We're hugely excited about enterprise data services, and have some thoughts as to how they fit within a Cairngorm architecture; we're still coalescing our thoughts on this internally, and will present our thoughts in a future Cairngorm 2.0 alpha release. If there's anything else that you'd like to see in Cairngorm 2.0, by all means let us know. Our aim is as ever to keep Cairngorm lightweight, to keep it generic, and to not throw into it all the things that others wish were in the Flex product (so we won't add Internationalisation !). That we have reduced the number of classes in Cairngorm 2.0 from Cairngorm 0.99 is proof that we are moving forward in our aim, not moving away from it.
"In sculpture, perfection is attained not when there is nothing left to add, but when there is nothing left to take away"
We look forward to your thoughts.
Posted by swebster at 06:17 PM | Comments (0)
Cairngorm 2.0 Alpha available for Flex 2.0 Beta Build
The release of Cairngorm 2.0 has been very much predicated on the release of the beta build of Flex that was made publically available yesterday - with that announcement out of the way, I'm delighted that we can now make an alpha build of Cairngorm 2.0 available to you here .
Let me tell you where we've come from, and where we're going. We're very much embracing the "alpha software" culture that surrounds the Adobe Labs project - we're giving out software that's early in it's cycle, so that you can play with it, so that you can feedback to us on it. Our philosophy with Cairngorm has always been that it will not be implementation of theoretical discussion on what best-practices could be, but will reflect techniques and approaches that we are using with success on real-world Flex consulting engagements. What you've got, is where we're at so far that we're confident releasing in that vein.
As best we could achieve, we've kept the APIs for Cairngorm 2.0 alpha the same as they were for Cairngorm 0.99; in doing so, we've ported to AS3.0 and leveraged the Flex 2 framework and ActionScript 3.0 as we think best right now. The purpose of this blog entry is just to get the code in your hands, and let you get a Cairngorm 2.0 + Flex 2 sample up and running in the new Flex Builder build as soon as possible. In upcoming blog posts, we'll walk through some of the things that have happened from 0.99 to 2.0, and some of the things we're thinking about. For now, here's how to get going with the zip.
Installing Cairngorm 2.0 Login Sample
- Extract the zip file into a local directory on your machine - for purposes of these instructions, let's call it c:\dev\cairngorm2\.
- Launch Flex Builder 2 and choose "New Project" from the File menu. Create a new Flex project.
- In answer to "Will this project be using Enterprise Services", choose "No".
- In the following screen in the new project wizard, give the project name "CairngormLogin", set the Project Location to "c:\dev\cairngorm2\" and set the Main application file to "CairngormLogin.mxml"
- Press the "Finish" button
You should now have a new Flex project, with CairngormLogin.mxml opened and ready to run. Press the run button on the FlexBuilder toolbar, and the application should compile and launch into your browser.
The CairngormLogin application is by no means intended to be a showcase for Cairngorm; it is a barebones application that allows you to prove your Cairngorm installation is working, and demonstrates a little of the usage of the API.
In upcoming blog posts, we'll discuss the design features of the current alpha build, and we'll discuss some of the future additions we'll add to the alpha. We'll ensure that by the time Flex 2 launches, you have a stable build of Cairngorm 2.0 to accompany it.
The ModelLocator implementation is one of the key differences in Cairngorm 2.0, reflecting the fact that you can no longer bind to statics with Flex 2.0. In building Cairngorm 2.0, and moving to the singleton approach we have at present, we uncovered a binding issue in the previous Flex alpha. The Flex team (who recognise how many of our Flex customers are basing their architectures upon Cairngorm) responded incredibly well, prioritised fixing this issue for the new beta build, so that you could have Cairngorm 2.0 to accompany this beta.
So, big thanks to the Flex team. In addition, big thanks to the rest of the Cairngorm committee who have debated and approved the various changes we've made, and thanks to the various contributors - notably Alex Uhlmann and Alistair McLeod of Adobe Consulting - who have made this build happen.
Find us on flexcoders if you want to discuss the release in detail; I'm just delighted we can make this build available to you all now !
Posted by swebster at 04:54 PM | Comments (2)