Skip to main content
A
Anonymous
January 7, 2011
Answered

Decoupling Presentation from Domain - How's that?

  • January 7, 2011
  • 2 replies
  • 2257 views

Hi there,

Beeing interested in flex frameworks, i just made my way through the cairngorm 3 guidlines and diving into parsley - and i love what i see sofar.

Nevertheless one big question came up for me, regarding the decoupling of presentation and domain through injected presentation models as explained within the guidelines and used within both cairngorm's and parsley's tutorials:

Say i want to design a custom mxml component for presenting some data collection (maybe a datagrid component with some visual extras). Now i would want to reuse this component for representing several types of data collection, maybe with different sources and needs for data processing. If i understand the pm pattern correctly i would implement different presentation models (maybe against an interface).

At this point i'm confused how to reuse my mxml component: i have to inject one presentation model into it but how can i than use the same component with another pm injected?

I thought of inherit the mxml component but i think that wouldn't work in a nice way because the component interns are coupled with the injected pm via bindings. I suppose thats just a misunderstanding of the pattern so, can somebody give me a hint?

Thanks in advance...jdee

This topic has been closed for replies.
Correct answer

If it is a component you are wanting to use in several different circumstances I would personally follow the way Adobe have built their own internal components.

It is quite easy to follow their components in the SDK source code. You can see how they define an ActionScript component and the associated Spark Skin.

If your component requires custom data in a particular format I would recommend writing custom interfaces that your data would implement.

As a bonus if you do this rather than attempting to use the Cairngorm [Inject] method you will also be able to use the custom component in other projects that may not rely on Cairngorm or Parsley.

If by component you are meaning a bigger piece of functionality ... eg. a Form with several fields, then I would recommend the Cairngorm methodology rather than following the Spark component format.

Hope that helps

2 replies

A
Anonymous
Correct answer
February 3, 2011

If it is a component you are wanting to use in several different circumstances I would personally follow the way Adobe have built their own internal components.

It is quite easy to follow their components in the SDK source code. You can see how they define an ActionScript component and the associated Spark Skin.

If your component requires custom data in a particular format I would recommend writing custom interfaces that your data would implement.

As a bonus if you do this rather than attempting to use the Cairngorm [Inject] method you will also be able to use the custom component in other projects that may not rely on Cairngorm or Parsley.

If by component you are meaning a bigger piece of functionality ... eg. a Form with several fields, then I would recommend the Cairngorm methodology rather than following the Spark component format.

Hope that helps

J
jgf11
Participant
January 8, 2011

I'm in the same boat as you learning this stuff. This is my take.

The presentation model is a combination of a value object pattern including properties for visual component state.

The Spark MXML namespace has the states/State nodes and this is the type of stuff that the presentation model contains... Things like whether a button is depressed or not, the tab page of a component, whether you are in a list or add or loading state etc.

The value object side of the Presentation model pattern pertains to the data elements being captured in your visual component. These don't get swapped out.

Theres' a one to one mapping between the MXML visual component and the AS3 Presentation model object.

What happens is binding and events come into play to bind the presentation model objects to the domain model. So you end up with things like PublishSubscribe, Publish, MessageHandler metatags Parsley adds to the mix. Then you'll have a commands that Subscribe and Dispatch events that sit in the middle.

Other people may be able to elaborate on this more eloquently. I'd suggest taking a look at this presentation

http://tv.adobe.com/watch/max-2010-develop/flexactionscript-30-architecture-and-dependency-injection-frameworks-overview/

The code is hosted here

https://github.com/pwalczyszyn/MAX-2010-Projects

And Piotr's blog is here - where you'll find the PHP - Zend server-side stuff

http://www.riaspace.com/

For me the beauty of this is the fact the script gets broken out of the MXML so you can use FlexUnit effectively. This is far superior to Cairngorm 2 and older school approaches. After seeing Piotr's presentation I also think Parsley is the best approach because the events forgo the need for a global singleton that the other micro architectures seem to require.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices