Hi
Scott,
I
think that your understanding of the framework is pretty much
correct.
The
way I look at ViewHelpers is that if you need to make any changes to the bit
that the visual part of the App - the View then the code for this should goonly
in that Views ViewHelper. For example the user ticks a tick box and the change
event for the tick box calls a method in the ViewHelper of a StatusView
Component. The method changes some Text of the StatusView to reflect the new
status. So the code is always in a logical place rather than bitsof
view control code being distributed all over.
Before
adopting the Cairngorm Framework I found it hard going. The most difficult part
of Flex without the Cairngorm (or similar) framework is
locating Objects/Components from another Object/Component and
standardizing this method. In fact I've taken the whole ethos of these Framework
"Patterns" on board, and added a few extras. After looking at the
ViewLocator pattern I added a ValueObjectLocator that allowed me to easily
access the Apps Data Models from whatever Component or ViewHelper I happen to be
in.
The
cairngorm framework has vastly expanded my understanding of Object Oriented
programming and at the same time made my Flex Apps much more understandableand
maintainable.
I
greatly thank Steven Webster and the Cairngorm team for their
efforts.
Regards,
Simon
Fifield
-----Original Message-----I'm currently getting ready to begin a long journey in FLEX
From: Scott Barnes [mailto:[EMAIL PROTECTED]
Sent: 17 March 2005 02:36
To: [email protected]
Subject: [flexcoders] Cairngorm for a newbie :)
development for a bunch of systems here at work.
I've been reading up as much as i can on cairngorm and trying to
figure out its value in FLEX and whether I should adopt it or plough
on without it.
So far I've watched Robin Hilliards Breeze preso, sampled some example
cairngorm applications from both I2 guys and Robin.
I've outlined some summary notes below, and would absolutely love it
if someone here could correct them or expand on them to enableme to
understand the cairngorm luv :)
Heres what I've gathered so far:
- formalised approach to command subscriptions, in that a controller
is established which registers itself against commands for both Views
and Models - but in a relatively simplified syntax (ie addCommand)
- Seperating ViewPods from logic via "ViewHelpers". It appears that
the framework allows a developer to add "behaviours" or "logic" to a
view but in a way that its not coupled with that said view (ie i
assume you could add a ViewHelper to other ViewPods? - yet all feed
off the one instance/codebase).
- Templated Command Objects : it seems to me that the whole Command
concept has established a base template to work from, so that
onResult, onFault and execute are automatically invoked per command? -
then the developer can just fill in the blanks based on the event
type?
- ViewLocator - kind of reminds me of DHTML's
document.getElementById() in that it appears each ViewHelper registers
itself within cairngorm and the ViewLocator simply provides a dynamic
bridge between the actual view and the object requesting its location?
or something like that?
Thats my note so far, and again I do apologise if its inaccurate in
anyway but i'm trying to wrap my headspace into how it implements MVC
and why its used.
If this is Offtopic I do apologise but *poke* *prod* a "Getting
Started Guide" would of been great ;) heheheheh
--
Regards,
Scott Barnes
http://www.mossyblog.com
