Looking forward to speak at Adobe DevSummit @Chennai 24/Nov & @Hyd 1/Dec on Topic “Integration of Spring with BlazeDS and CairngormUM (Deep Dive)”

The Presentation Document : link &
Presentation

DevSummit

Feeling nostalgic for a bit of stinky, steamtrain action, we took a trip through Cairngorm national park.

Choo choooo

It was pretty authentic. There was even a gruff, soot covered engineer. I felt like Ringo Starr should have been narrating in the background.

The real deal

There wasn’t really much to see on the way, Vanessa even had a little nap. The train was cool though.

Nap time

We based ourselves at a camping ground just out of Inverness in Dingwall. We attempted our second disposable BBQ experiment, this time with more success.

I feel a lot of anxiety when cooking a disposable BBQ. There’s one shot at it, if you don’t time it properly and get it all right up front then you are screwed. In this sense the disposable BBQ is the Waterfall of the grilling world. I prefer an approach where you can always chuck the steak back on the hotplate if it is too pink.

As you can see though, Vanessa was in her element – comandeering a disposable BBQ just as efficiently as a real one.

Everybody cook or the sausage gets it!

Here we  also experienced our first airbed failure. Early in the morning I heard a rrrrptt…phwoosh noise. It wasn’t just the after effects of the BBQ either. With that, the Argos airbed hit the bin and an £8 replacement was procured from Tesco.

Oh Tesco, our saviour. We went to Tesco pretty much every day, mainly because we had no means of refrigeration. I think we would have camped in Tesco if we could get away with it. It would have been like Dawn of the Dead, except without zombies. So not nearly as cool in that sense.

We took the obligatory trip over Loch Ness. No sign of the monster. I was genuinely disappointed.

No monster

We also took a trip out to the Black Isle Brewery. I love checking out smaller microbreweries, they always have something a bit different. The oatmeal stout was my favourite.

On the way out there we came across a friendly cow that we dubbed Daisy. She was very quick with the tongue when you got close enough. Daisy may or may not have been her real name.

Daisy

Have got about a dozen or so non-festival beers from the past month to catch up on at a later date, a couple of good ones to recommend but will do the festival and fight notes first or else I’ll never get round to it. The fight thoughts first:

- Audley Harrison wins Prizefighters. And hilariously thinks that he’d have been a world champion but for crap promoting by Warren. Now, I don’t know about you, but I think his lack of world title is correlated to the fact that he sucks and is unmarketable. His fights are boring apart from the odd occasion when he gets knocked out. If he was to get a title shot against, say, Valuev, that might be the worst fight in the history of professional boxing.

- Floyd Mayweather beats Marquez. Thank god for that, bring on Pacquiao. Post-bout interview was hilariously bad, sure Mosley is good but he’s not seriously going to get a shot at Mayweather as he’s only back to make cash money, and that fight, while it makes sense, wouldn’t really cut it.

- UFC 103 didn’t look that great a card so I passed on it. Return of Belfort and dos Santos knocking Mirko into retirement. 104 looks a lot better, even the undercard looks exciting.

- LOL Kimbo.

Beer festival then. Was a lot better than last years, due to it not being freezing, actually having the second marquee up, solid conditions underfoot and a great selection of beers. Was a bit windy on the Saturday, but oh well. The beer:

206 – Fyfe Lemon Twist (4.2%) – 5.5, is noticably lemony, light and thin, beyond the citrusness is a bland, unimaginative ale

207 – Tring Mansion Mild (3.7%) – 8, slightly fruity nose, hints of cherry and raspberry, not overly heavy either

208 – Great Heck Dave (3.8%) – 7, dark ale with smoky roasted taste, while not being too malty

209 – Cairngorm Sheepshaggers’ Gold (4.5%) – 8, slight ginger hints, a lot fuller and stronger than previous beers, very drinkable golden premium beer

210 – Brass Monkey Tamarind Mild (3.6%) – 6.5, looks like a reddish bitter rather than a mild, is ok, barely tastes like a mild either

211 – Naylor’s Roaring Ruby (4.1%) – 7, calling it ruby would be wrong, just looks and tastes like a solid golden bitter

212 – Sheffield Crucible Best (3.8%) – 6.5, a decent bitter that seems stronger than the ABV would suggest

213 – Isle of Purbeck Studland Bay (4.5%) – 7, a rich, punchy bitter

214 – Wilkins Cider (6.0%) – 6.5, on the sweet side, decent enough to drink, a bit cloudy

215 – Bradfield Sheffield Tigers (4.8%) – 7.5, recommended stronger ale

216 – Brew Company Hop Ripper (4.3%) – 6.5, light, hoppy, dry, bad to start with but improves quickly

217 – Kelham Island Best Bitter (3.8%) – 6, looks like a bitter, tastes like a bitter, is ok but a bit dull and a touch on the dry side

218 – Tryst Bla’tham (4.0%) – 7.5, seems hoppy in the nose, is slightly tangy and sour but in a good way, slightly citrusy, improves a lot down the pint

219 – Acorn Sovereign (4.4%) – 6, darker ale, malty smell, strong bodied but with a dull malty taste

220 – Daleside Old Leg Over (3.9%) – 7, good bitter, touch on the dark side with ruby hints

221 – Crown Smokin Oktoberfest (5.7%) – 8, pleasant colour, strength is noticable, nice subtlety with flavours

Gravity is an ActionScript framework that offers a modularization strategy inspired by implementation of OSGi . In short, it’s a dynamic plug-in framework for ActionScript, Flex and AIR applications. While geared towards addressing challenges in the Enterprise RIA space, there’s nothing stopping developers from using this technology any time their project(s) call for modularization and loose coupling.

One exciting feature in the pipeline will be support for plug-ins compiled under different versions of the Flex SDK. This allows developers to roll out new functionality without having to refactor and re-compile existing code. (We are not using Flex modules under the hood) Another important goal was to avoid being prescriptive as to how you actually develop your application code. i.e. Gravity will “play nice” with the likes of Cairngorm and other frameworks/best-practices.

As for the history of this project, it’s been used internally @Adobe and in product dating back a couple of years now. (and yes, we deserve some lashings for not getting this out sooner) Throughout that time momentum of OSGi has continued onward and upward, particularly in the Java and mobile space. More recently, in the Flex realm with the release of Potomac. Potomac takes different approach than Gravity but is exciting to see and offers further validation of OSGi in the client space. (They’ve got a great IDE plug-in as well) The more the merrier!

The initial Gravity release will contain the framework, ASDocs and supporting documentation (not extensive at first, more of a quick start) as well as sample projects. Look for it on Adobe Labs in the coming 2-3 weeks! We’ll be following the open source model adopted by the Flex SDK team in due course.

Cheers,

Stacy

Links to Frameworks BlazeDS, in the /blazeds directory Cairngorm, in the /cairngorm directory Durango, in the /durango directory Flex SDK, in the /flex/sdk directory FlexPMD, in the /flexpmd directory FlexUnit, in the /flexunit directory Open Source Media Framework (OSMF), in the /osmf directory Text Layout Framework (TLF), in the /flex/sdk/trunk/frameworks/projects/textLayout directory. Summary BlazeDS Access as: http://opensource.adobe.com/svn/opensource/blazeds Commits forum: http://www.adobeforums.com/webx/.3c061bb9 Cairngorm Access as: http://opensource.adobe.com/svn/opensource/blazeds Commits forum: http://www.adobeforums.com/webx/.59b5b4ec/ Durango Access as: http://opensource.adobe.com/svn/opensource/durango Flex SDK Access as: http://opensource.adobe.com/svn/opensource/flex/sdk Commits forum: http://www.adobeforums.com/webx/.3c061177 FlexPMD Access as: http://opensource.adobe.com/svn/opensource/flexpmd FlexUnit Access as: http://opensource.adobe.com/svn/opensource/flexunit Commits forum: http://www.adobeforums.com/webx/.59b62b94 Open Source Media Framework (OSMF) Access as: http://opensource.adobe.com/svn/opensource/osmf Commits forum: http://forums.adobe.com/community/opensource/osmf/commits Text Layout Framework (TLF) Access as:http://opensource.adobe.com/svn/opensource/flex/sdk/trunk/frameworks/projects/textLayout

Adobe Open Source About Feedback Contributor Agreement  Projects BlazeDS Cairngorm Durango Flex SDK FlexPMD FlexUnit Generic Image Library Open Source Media Framework Text Layout Framework Webkit More ›

Projects Adobe is active in Open Source projects. The following are a number of our contributions and commitments to open source. BlazeDS Cairngorm Durango Extensible Metadata Platform (XMP) Flash Ajax Video Component Flex SDK FlexPMD FlexUnit Generic Image Library Open Source Media Framework Adobe Media Gallery Adobe Source Libraries Tamarin Text Layout Framework Webkit BlazeDS BlazeDS is the server-based Java remoting and web messaging technology that enables developers to easily connect to back-end distributed data and push data in real-time to Adobe® Flex™ and Adobe AIR™ applications for more responsive rich Internet application (RIA) experiences. Previously available only as part of Adobe LiveCycle® Data Services ES, Adobe is announcing its plans to contribute the proven BlazeDS technologies to the community under the LGPL v3. BlazeDS gives the rapidly growing Adobe developer community free access to the powerful remoting and messaging technologies developed by Adobe. Home | Downloads | Source | Documentation Cairngorm Cairngorm is the lightweight micro-architecture for rich Internet applications built in Flex or AIR. A collaboration of recognized design patterns, Cairngorm exemplifies and encourages best-practices for RIA development advocated by Adobe Consulting, encourages best-practice leverage of the underlying Flex framework, while making it easier for medium to large teams of software engineers deliver medium to large scale, mission-critical rich Internet applications. Previously available only as Adobe Consulting releases through labs.adobe.com, Cairngorm is now evolving towards a project that will invite community leaders and enterprise adopters to partner with Adobe Consulting in the ongoing development of Cairngorm. Home | Downloads | Source | Documentation Durango Durango is a framework that allows developers to build Adobe AIR applications that can be customized by end-users. Durango allows developers, designers and end-users to easily mashup independent components to create new applications or extend existing Durango-enabled applications. These “mashable” components can be visual or non-visual (e.g., web services). Designers and developers can rapidly create prototype applications and then generate Adobe Flex MXML source projects for further development. End-users can take parts of their favorite applications and bring them together in new ways. Home | Downloads | Source | Documentation Extensible Metadata Platform (XMP) Adobe’s Extensible Metadata Platform (XMP) is a labeling technology that allows you to embed data about a file, known as metadata, into the file itself. With XMP, desktop applications and back-end publishing systems gain a common method for capturing, sharing, and leveraging this valuable metadata—opening the door for more efficient job processing, workflow automation, and rights management, among many other possibilities. The XMP SDK is available as open source. Home | Downloads Flash Ajax Video Component The Flash Ajax Video (FAVideo) component is a small, open source Flash component that you can use to provide video playback within an Ajax application. It exposes all of the formatting and video playback controls necessary to build a video player customized entirely using HTML and Javascript. Home | Downloads Flex SDK Adobe® Flex™ is a cross platform, open source framework for creating rich Internet applications that run identically in all major browsers and operating systems. The Adobe® Flex™ SDK is the foundation of Flex, providing the core Flex compilers, component library and debugger. Using only the free SDK and an IDE of your choice, you can build and deploy rich Flex applications. Home | Downloads | Source | Documentation FlexPMD FlexPMD is a tool that helps to improve code quality by auditing any AS3/Flex source directory and detecting common bad practices, such as Unused code (functions, variables, constants, etc.), Over-complex code (nested loops, too many conditionals, etc.), Over-long code (classes, methods, etc.), and Incorrect use of the Flex component lifecycle (commitProperties, etc.). Home | Downloads | Source FlexUnit FlexUnit is a unit testing framework for Flex and ActionScript 3.0 applications and libraries. It mimics the functionality of JUnit, a Java unit testing framework, and comes with a graphical test runner. Home | Downloads | Source Generic Image Library Generic Image Library (GIL) is a C++ generic library which allows for writing generic imaging algorithms with performance comparable to hand-writing for a particular image type. Home | Downloads | Documentation Open Source Media Framework Open Source Media Framework enables developers to easily assemble pluggable components to create high-quality, full-featured playback experiences. The open aspect of the framework enables collaborative development for web video monetization, with lower costs and faster turnaround. Home | Downloads | Source | Documentation Adobe Media Gallery The Adobe Media Gallery (AMG) is a Flash web photo and video gallery whose appearance and behavior can be customized via XML files. Home | Downloads | Source | Documentation Adobe Source Libraries The Adobe Source Libraries (ASL) are a collection of C++ libraries building foundation technology to allow the construction of commercial applications by assembling generic algorithms through declarative descriptions. Updates monthly. Home | Downloads | Source | Documentation Tamarin The Tamarin project, which is based on code contributed from Adobe, is designed to implement an open engine for ActionScript. Tamarin will be used by Mozilla within the next generation of SpiderMonkey, the core JavaScript engine embedded in Firefox®, Mozilla’s free Web browser, as well as within the ActionScript™ Virtual Machine within Adobe® Flash® Player. Developers interested in working on Tamarin code in the Mozilla CVS repository via the project page located at www.mozilla.org/projects/tamarin/. Contributions to the code will be managed by a governing body of developers from both Adobe and Mozilla. Home Text Layout Framework The Text Layout Framework is an extensible ActionScript library, built on the new text engine in Adobe Flash Player 10 and Adobe AIR 1.5, which delivers advanced, easy-to-integrate typographic and text layout features for rich, sophisticated and innovative typography on the web. The framework is designed to be used with Adobe Flex or Adobe Flash Professional and is included in Flex 4, code named “Gumbo”. Developers can use or extend existing components, or use the framework to create their own text components. Home Webkit The WebKit library is used to render HTML and execute JavaScript in Adobe® AIR™. Adobe AIR allows web developers to deploy rich Internet applications on the desktop. Our plan is to contribute our changes back to the WebKit community in the near future. We are currently working on getting the code smoothly integrated into the WebKit source tree. We hope to make our contributions included in the WebKit open source project soon. Home | Source

]]> http://jaibeermalik.wordpress.com/2009/08/28/flex-enterprise-security-implementation-using-chimp-permission-based-filtering-component/ Fri, 28 Aug 2009 03:22:54 +0000 Jai http://jaibeermalik.wordpress.com/2009/08/28/flex-enterprise-security-implementation-using-chimp-permission-based-filtering-component/ http://jaibeermalik.wordpress.com/2009/08/27/flex-choosing-the-right-flex-data-transfer-strategy-and-designing-the-application-accordingly/ Thu, 27 Aug 2009 03:59:03 +0000 Jai http://jaibeermalik.wordpress.com/2009/08/27/flex-choosing-the-right-flex-data-transfer-strategy-and-designing-the-application-accordingly/ http://jaibeermalik.wordpress.com/2009/08/26/flex-cairngorm-view-notifications-strategies-responders-from-command-to-view/ Wed, 26 Aug 2009 03:32:37 +0000 Jai http://jaibeermalik.wordpress.com/2009/08/26/flex-cairngorm-view-notifications-strategies-responders-from-command-to-view/ http://jaibeermalik.wordpress.com/2009/08/24/flex-springactionscript-ioc-springactionscript-cairngorm-extension-sample-code-examples/ Mon, 24 Aug 2009 03:46:44 +0000 Jai http://jaibeermalik.wordpress.com/2009/08/24/flex-springactionscript-ioc-springactionscript-cairngorm-extension-sample-code-examples/ http://jwopitz.wordpress.com/2009/08/21/solution-found-cairngorm-mate-puremvc/ Fri, 21 Aug 2009 07:05:02 +0000 jwopitz http://jwopitz.wordpress.com/2009/08/21/solution-found-cairngorm-mate-puremvc/

Notes

• the code samples and sample application utilized Flex 4 SDK
• I am using a patched version of Mate to accommodate the Flex 4 SDK
• I will post further updates to this post so stay tuned
• the sample application is UGLY, so don’t expect anything great here folks.   Just enter some text in both text fields and hit save.  Tada.  It gets sent to two hidden labels.
• you can download the sample application here – link

Goals

As of late I have been quite obsessive about finding a solution in which an application’s MVC constituents could be highly decoupled.  Some of the requirements in this solution are:

• view classes have no knowledge of UX logic (no dispatching of CairngormEvents)
• view classes have no knowledge of Model objects nor {binding} to objects outside their local members
• view classes are ignorant of any mediators wrapping them
• command classes are ignorant of any mediators dispatching any UX logic events
• command classes have no knowledge of Model objects outside of data payloads riding in on execution parameters
• avoiding Singletons where possible

Don’t you just love lists?  I do   This at first sound very restrictive especially to those of us who are long-time Cairngorm users.  It is quite easy to {bind} a view to a model class and be done with it.  This is great in mocking up prototypes quickly but is a shortcut that leads to plenty of headaches later on.  It’s quite easy to perform UX logic inside a Command class and then directly wire into a ModelLocator.  Again, this proves to be a pain if you are looking to do some sort of unit testing or want to decouple from your Model classes.

So let’s look at a few good things that each of these frameworks provide such that we can pick out the best and discard the rest.

Cairngorm

• Command pattern – being able to abstract out UX logic into commands is just great.  It adheres to the MVC paradigm so long as we are able to decouple the constituents.

PureMVC

• Mediator pattern – this allows us to accomplish points 1 & 2 above in the requirements.  It does mean that mediators are obviously knowledgeable about their views but its a one-way coupling issue.

Maté

• Dependency Injection – the ultimate solution in decoupling all MVC actors.  Maté’s unique binding solution for DI is great in that we needn’t have to implement anything aside from the Injector mechanisms.  This affords us the ability to also have multiple DI maps for various scenarios, whether that be UI testing, unit testing or whatever.
• EventMaps – In a general sense the EventMap is a great way to delegate the task of doing all the Controller logic that normally we have to do ourselves in Cairngorm or PureMVC.

So there you have it: An outline of how I plan to use these 3 frameworks to build a highly decoupled app in which all our MVC actors are basically plug n’ play classes.  Cool sounding eh?  Ok, now that that is out of the way I need to explain a few specifics with respect to the Command and Mediator pattern and how I use them.

Command classes

Using an out of the box Cairngorm ICommand is a bit restrictive in this solution so we are going to borrow the interface and change it up a bit.  Rather than this:

execute (event:CairngormEvent):void

we need something a bit more loose like so:

execute (params:Object):void

In this, we are simply accommodating some of the restrictive mechanisms found in how Maté handles the event system.  You could wire it in many ways but for the most direct route let’s stick with this.  The other thing we need to do is have our Command classes extend event dispatcher so that we can signal back to Maté that either the response logic or fault logic has commenced.  So here is a sample of how the IResponder portion works in these commands:

result (data:Object):void
{
     //assuming your response from some service,
     //say an XML response that needs massaging to an AS3 Value Object
     var vo:SomeValueObject = data;

     var resultEvt:DynamicEvent = new DynamicEvent("result");
     resultEvt.data = vo;
     dispatchEvent(resultEvt);
}

fault (info:Object):void
 {
    var faultEvt:DynamicEvent = new DynamicEvent("fault");
    faultEvt.data = vo;
    dispatchEvent(faultEvt);
 }

So this should be roughly inline with what most Cairngorm users do on a regular basis.

Mediator classes

It’s not like PureMVC invented the mediator pattern, but it certainly brought the valued pattern to light to many Flex developers.  There are no particular implementations from PureMVC or anywhere else, this is just my spin on it:

Views should implement a simple marker interface called IMediatorClient.  That’s it.  If you are using Flex 4 SDK, then remember currently code hinting will not work when typing “interface” in your MXML tag.  It will compile just fine.  At least it did for me.

Mediators happen to implement the following interface:

public interface IMediator
{
   function get target ():IMediatorClient;
   function registerTarget (target:IMediatorClient):void;
}

Now we need keep in mind a few Maté specific things here.  Because Maté happens to leverage the display list and some of the inner workings of the Flex system manager we have three choice in how Maté gets wind of our events.

1. dispatch bubbling events from our IMediatorClient (because all views will be IEventDispatchers by their very nature)
2. wire in a specific Dispatcher from Maté (this means bringing in Maté specific code into our pristine code. no….)
3. find some other solution that probably entails a central event dispatcher that then wires into an EventMap

Obviously solution #1 is the most unobtrusive and easiest for OCD folks (like me) to deal with.  Let’s stick with that for now.   Besides, a bubbles event is not such a bad thing is it?  Just make sure that you are using some unique event types otherwise you might trigger unexpected handlers elsewhere in your application.

So let’s see how we wire these puppies up into Maté.

Maté wirings

First up is the what I am calling a Mediator Map.  Simply put it is a way to wrap your IMediatorClient views into IMediators without specifically having the wiring code in anything but Maté.  Note that I am doing this in Flex 4 SDK and thus requires the use of the declarations tag.

<?xml version="1.0" encoding="utf-8"?>
<mate:EventMap
xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/halo" xmlns:mate="http://mate.asfusion.com/">

<fx:Script>
<![CDATA[

import app.view.*;
import app.view.mediators.*;

]]>
</fx:Script>
<fx:Declarations>
    <mate:Injectors target="{SampleIMediatorClient}" debug="true">
       <mate:MethodInvoker generator="{SampleIMediator}" method="registerTarget"
          arguments {event.injectorTarget}"/>
     </mate:Injectors>
</fx:Declarations>
</mate:EventMap>

So this MediatorMap would be placed on your Application level class.  Simple enough right?  The cool thing is that this autowires a view to a mediator when the view gets attached to the display list.  And because Maté is in charge of caching the instances it creates, you will soon see that the mediator can be referenced in the DI map below.

Dependency Injection map

So this next map is where we are basically injecting model classes into mediators which in turn affect changes on the views through whatever logic you so desire.  I like using the IDataRenderer interface alot as it is easy to remember.  Check it out:

<?xml version="1.0" encoding="utf-8"?>
<mate:EventMap
 xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/halo" xmlns:mate="http://mate.asfusion.com/">

 <fx:Script>
 <![CDATA[

 import app.model.*;    
 import app.view.*;
 import app.view.mediators.*;

 ]]>
 </fx:Script>

 <fx:Declarations>

 <mate:Injectors target="{CurrentUserViewMediator}">
 <mate:PropertyInjector targetKey="data" source="{UsersManager}" sourceKey="currentUser"/>
 </mate:Injectors>

 </fx:Declarations>

</mate:EventMap>

So all this does is say, when we make a change to the currentUser on the UsersManager class, we want to let the CurrentUserViewMediator know about the change.  Maté handles the binding mechanisms internally.  Lastly I need to show you how the command classes are wired into the EventMap.

EventHandlerMap & Commands

I had written an earlier post on this but I will post it here too.  So this is kinda the tricky part about Cairngorm and Mate playing well together.  Remember we had to make our Commands dispatch events?  Well here is why.  The AsyncCommandInvoker class in Mate expects to hook into events of specific types.  Since our commands implement IResponder, why not keep it simple and just have it expect the same from the event types.

<?xml version="1.0" encoding="utf-8"?>
<mate:EventMap
 xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/halo" xmlns:mate="http://mate.asfusion.com/">

 <fx:Script>
 <![CDATA[

 import app.controller.commands.*;
 import app.model.*;
 import app.view.*;
 import app.view.mediators.*;

 import com.adobe.cairngorm.control.*;

 import mx.events.*;

 ]]>
 </fx:Script>

 <fx:Declarations>

 <mate:EventHandlers type="saveUser">
    <mate:AsyncCommandInvoker generator="{SaveUserCommand}" successType="result">
      <mate:successHandlers>
        <mate:PropertySetter generator="{UsersManager}" targetKey="currentUser"
           source="{scope.currentEvent.data}"/>
      </mate:successHandlers>
    </mate:AsyncCommandInvoker>
 </mate:EventHandlers>

 </fx:Declarations>

</mate:EventMap>

Notice the successType in the AsyncCommandInvoker.  This is that event we dispatched from the result method on the command.  Similarly there is a faultType which we would dispatch “fault” there.  So one question you might have is, “where is the saveUser event type getting dispatched?”.  So in this example, I had my mediator wrapping the EditUserView tie into a save button click event.  Then it dispatched an event from the view that bubbled up with the type saveUser.

Conclusion

Well there you have it, a quick mash up of how to combine the best elements from the various MVC frameworks along with some cool IoC/DI wiring from Maté.  Is it perfect?  Far from it.  It’s funny how these things come in spurts.  I hadn’t made any progress for a long time, reading up on things like Parsley, Swiz, Spring Actionscript and RobotLegs only to find that I was dissatisfied.  To tell the truth I didn’t even give these other framework a chance.  I was lazy and didn’t feel like learning something new when I knew that I could do it pretty much with Mate, Cairngorm and PureMVC.

I am psyched to try this in a bigger application at some point.  I do have a few reservations regarding Mate, specifically with respect to cached instances and all the behind-the-scenes {binding} that takes place.  How does this affect performance and memory?  The other big issues is that debugging this is a pain.  I haven’t figured out all the intricacies of Mate and if a problem occurs outside of your main actors, debugging gets difficult.  Lastly, the idea of Singletons have been removed from your MVC actors but isn’t this then just passed on to Mate in some sense?  Well not to fret but just some things to think about.

Let me know your thoughts and ideas.

Learn and understand  cairngorm framework  in very simple manner by following tutorials .

1)Part-1

2)Part-2

The above aricles are posted by DavidTucker. I found them really much helpful .  If want to know more you can checkout the link on DavidTucker blog

If you know any thing on Cairngorm, which you want to share or any other link related to Cairngorm or any other Flex fremework, then welcome to post the comment.

First off, note the word “paradigm” rather than the more commonly used word “framework”.  As a self proclaimed pragmatist, the word paradigm seems more fitting in a world where no one shoe fits all.  Aren’t you tired of hearing the old debate of “which MVC framework is best”?  I am tired of the whole Cairngorm, PureMVC, Maté, Swiz, blah blah blah….  The dealo is that they all offer some strong solutions for common problems.  Certainly having NO MVC infrastructure in your application is a poor choice.  I have indeed been on a quest to find some solution in which I could utilize all the best from each library while leaving behind the bad.

Now I should preface this by saying I have no formal training in Computer Science.  I have been on a quest for a good dependency injection solution for a long time not knowing that was what it was called.  Besides, what’s in a name?  Does dependency injection or inversion of control really convey to the layperson the idea of wiring up an application?  I think I am fairly smart and I didn’t understand it even after reading Wikipedia on the subject.  To finish up here, let me compose a written goal(s) of what this post is all about and then I will dive into each point where applicable.  Some of these may be common knowledge but are still worth pointing out (pardon the “no-duh” points):

• hereinafter the word “framework” will refer to existing MVC constructs such as Cairngorm, PureMVC, Maté, etc.
• hereinafter the word “wiring” will refer to either an existing or proposed IoC/DI construct such as Spring Actionscript (formerly known as Prana), Maté’s Injector logic, etc.
• User eXperience is hereinafter referred to as UX.  Any and all executable logic, whether triggered by user interaction or through subsequent data manipulation is considered UX.
• application MVC constituents should be highly decoupled in the following manner:
  • view classes will be ignorant of any UX logic associated with their interactivity.  This will be accomplished either by a wiring mechanism similar to Maté’s EventHandlers in its EventMaps or PureMVC’s Mediators.
  • controller/command classes should function independently of one another such that particular UXs can be assembled via the wiring in a building block fashion.
  • data/model classes are to avoid ModelLocator implementations.  This will entail less {binding} and more verbose wiring logic.  This will accommodate modular application structures where Singletons are problematic.
• Leveraging the event-driven nature of the Flash Player is ideal.
• A solution that is Flex-agnostic is ideal.
• A solution that can either take an XML or MXML map is ideal.  Having the option to “compile” the wiring is nice in that it maps much like the DI of Maté.

So there are a few goals I have in mind.  Obviously existing frameworks and wiring solutions have tackled some of these but I feel that they are mostly intrusive.  People use the term “boilerplate” code in reference to Cairngorm but I’d rather say that Cairngorm give you enough rope to hang yourself with.  People claim that PureMVC’s mediator implementation makes for more classes but I’d rather say that it is simply the price you pay for decoupling your views from your UX logic.  People say Maté is alot of smoke and mirrors but I’d rather say the idea of IoC is new to Flex developers that we haven’t readily accepted the fact that it works.

If you would like to see some of the work I am doing on this, you can check out some of the Mediator/Maté hybrid mashup stuff I am working on here – http://subversion.assembla.com/svn/as3mediatorlib/trunk.

Please sound off and if you are interested in working on a solution please contact me.  Thanks.

UFC 100 quickly, because it was a longer time ago – disappointed imo. Mainly because it was fairly predictable in that Lesnar simply repeatedly punched Mir and showed that he’s not going to lose to a cheap submission again, GSP vs. Alves was more or less one way traffic as expected, Henderson – Bisping was briefly entertaining, but we really don’t need to see Hendo lose to Anderson Silva again in the future, Fitch’s fight was automatic, and only Akiyama/Belcher looked to be close (and imo Belcher won the fight). We should all take a minute to laugh at Stephan Bonnar for losing to someone old enough to be my grandfather, but the card just seemed to be a case of failing to live up to very high expectations.

Then we had the whole Fedor to UFC cocktease bullshit, the deal that was reportedly offered by Zuffa was insane, and M-1 are daft to turn it down, and equally crazy if they think that they can actually build up a decent promotion based around Fedor and, er, er, help please?

UFC 101 – Penn/Florian was pretty sucky, KenFlo never really threatened to do anything, Penn didn’t gas, did enough to win all of the first three rounds and finished nicely in the fourth. Silva/Griffin was awesome, mainly because Silva just owned from the minute he stepped into the arena. Sadollah/Hendricks was finished way too early, and as a result we managed to see Aaron Riley be simply too big for Shane Nelson, who needs to get himself to the WEC ASAP. I thought Kendall Grove did enough to win the second round against Ricardo Almeida, but still lost the fight, and if Pellegrino/Neer had been aborted after 30 seconds I don’t think anyone would have cared. An undercard bout between some Australian and some other guy was entertaining enough I guess.

UFC has a few problems in creating meaningful competitive fights right now. Lesnar is well above anyone else at heavyweight, and apart from Big Nog if he can bounce back against Couture in a few weeks, or Carwin/Velasquez down the road, there’s nobody that can really challenge. GSP and Anderson Silva are streets ahead of anyone at 170 and 185 respectively, and Penn looks to be too good for anyone at 155 as well. There could be some decent action at 205, but I don’t know who can obviously beat Machida right now. At least there there is a lot of competition between good fighters who could legitimately have a shot. I don’t know what they can do about it, other than have Silva move to 205 permanently (which isn’t going to happen, and he wouldn’t fight Lyoto anyway), and we don’t need to see GSP fight Silva either. If they can’t get Fedor despite throwing everything at him, I don’t see what’ll happen. Still, I’m excited about 102, the main event does nothing for me, but Jardine/Thiago Silva should be fun, I do like Jardine’s fights even though he somewhat sucks when fighting top-5 calibre at the weight, Maia/Marquardt should be awesome, and hopefully Brandon Vera will get owned again.

Quite a lot of beers to mention, not done any festivals of late, there’s some coming up in October, including Sheffield and one at my local. Without further ado:

177 – Three B’s Bobbins Bitter (3.8%) – 6.5, full flavoured, slightly dry and fruity

178 – TSA Ben Nevis (4.0%) – 7, full, slightly fruity and malty

179 – Holden’s Lambswool (4.5%) – 6.5, not bad, has an odd slightly malty taste

180 – Cottage Box Tunnel (4.3%) – 6, slightly malty, unchallenging bland ale

181 – Cottage Metropolitan (4.7%) – 7, well balanced, touches of fruit and malt

182 – Boggart Bog Eyed (4.0%) – 6.5, bit dry and hoppy, better than other beers they make.

183 – Phoenix St George’s Flag (4.3%) – 7, moderately dry, hoppy and refreshing

184 – Betwixt Skyline (3.5%) – 5, mundane, dull and heavy

185 – Derventio Et Tu Brutus (4.5%) – 6, unimaginative and slightly heavy

186 – Three Rivers Old Disreputable (5.2%) – 7.5, dark, sweet and liquoricey, almost like a dark mild

187 – Rudgate Brandt (3.9%) – 6.5, decent if a touch too malty

188 – Wentworth Small Copper (4.1%) – 6.5, tastes full to start, but weak aftertaste, ok, rich enough

189 – Phoenix Hopsack (3.8%) – 7.5, very drinkable, dry hoppy ale

190 – Slaters Howzat (3.8%) – 6.5, dark, malty and earthy, a bit better than similar beers

191 – Slaters Top Totty (4.0%) – 8, light ale, well balanced and drinkable

192 – Ossett Pale Ale (3.6%) – 7.5, pleasant light and hoppy session ale

193 – Cairngorm Nessie’s Monster Mash (4.4%) – 7, decent darker ale, bit malty and treacley, overrated

194 – Acorn Ginger Nuts (4.2%) – 7, decent lighter ale, ginger noticable but not dominant

195 – Lancaster Amber (3.7%) – 6, slightly dark amber ale, ok but not spectacular

196 – Northumberland Northumbria Ale (4.5%) – 6.5, slightly tangy golden ale on the hoppy side

197 – Springhead Liberty (3.8%) – 6.5, standard pale ale

198 – The Brew Co Dev Cat Brewers Gold (3.8%) – 6.5, light hoppy session ale with dry aftertaste

199 – Victoria Bitter (4.8%) – 7, an almost lager-bitter hybrid that’s on the malty side

200 – Thornbridge Lord Marples (4.0%) – 6, rather malty and a bit heavy

201 – Rudgate Flaxen Dane (4.2%) – 7.5, mildly hoppy, slight dry finish

202 – Northumberland Jolly Rogers (4.0%) – 5, darkish ale with awful aftertaste

Hi JavaFx fans,

This is the interesting and good news for us. We have Cairngorm framework for JavaFx too, it is exactly what we have it for Flex development. It is named by Cairngorm-FX. Surely it will help us to increase the productivity and time-saving. The guy from Cjtech.co.uk, developed this framework. It is available for download under MIT License.

Read the complete details from cjtech.co.uk.

Go to Download page .

Some Useful links for Cairngorm

Cairngorm overview and downlolad

http://opensource.adobe.com/wiki/display/cairngorm/Cairngorm

Cairngorm forums

http://forums.adobe.com/community/opensource/cairngorm

About Cairngorm

http://opensource.adobe.com/wiki/display/cairngorm/About

Recently, I embarked on a personal project to learn about the Mate Framework, which I’ve started hearing more and more about. We’ve successfully used Cairngorm in dozens of Flex/AIR projects at Enpresiv and I thought it was time to try out Mate (apparently pronounced mah-teh).

I’m glad I did, because it is an awesome framework with much flexibility making it suitable for many different types of projects. One of my favourite things about the framework is how quick and easy it is to integrate. It doesn’t force you to use all Mate concepts either, providing endless options for partial integration into existing projects that might just need a little structure.

One of the issues with Cairngorm that a lot of people have trouble with is easily responding to events/commands within a view (albeit the event that dispatched the event or not). I was happily surprised when I found out this is one of the easiest things to do within Mate, and there are two ways to do it!

Mate advocates the Dependency Injection pattern over the Model Locator pattern which Cairngorm advocates. Dependency Injection is a fantastic concept and truly promotes reusable views as the view needs no knowledge of the framework. Your view doesn’t really need to respond to an event directly, it just receives only the required or updated data it needs.

The second means for views to directly respond to events is using the Listener tag, which simply could not be any easier to work with.

I’ve worked up a basic yet focussed example on two options for repsonding to Mate events within views.

I plan on discussing other Mate features in future posts, but thought this was a great starting point as it’s the source of pain for many Cairngorm developers. Although, Universal Mind have released some extensions which make responding to events/commands within views much easier.