Thanks for clarifying; I hope you would.
However, I still think ARP is lighter weight; I define light weight as "more
files = more heavy". ARP doesn't have ViewLocators, ViewHelpers,
ModalLocator, etc.
My point is ViewHelper and ViewLocators; I don't see the point of
abstracting that away; Commands work just fine for dealing with the
deatails.
I get my data from data services and stick it in ModelLocator; would I not
do the same for a RemoteObject call? Get the data and hang it there for
Commands to grab?
We don't have data-binding in Flash like Flex does, so I agree, it is a
necessity for now for me to utilize my Commands to pull data off of it, and
give it to the View. If I were in Flex, I wouldn't have to do this stupid
step.
>>>>>
So rather than a Command class have to know to do:
_root.mainScreen.addressBook.addressEntry.forename.text = result.forename;
The Command class could instead say:
AddressBookViewHelper.setForename( result );
<<<<<
See, I see no problem with that; to me, that's a Command's job, and if he
can't take the heat, and needs another class to deal with extra typing...
good for him. For me, I'm fine with it.
I don't recall calling it evil, but if I did, I mis-spoke. I do not
understand it, cause again, my Views don't change, and if they do, I'm not
nesting movieclips; I'm just calling getters and setters, and our dev cycle
is short, so having to change 5 lines of code because of a simple form name
change isn't a big deal; again, hard for me to see the justification in such
short projects.
----- Original Message -----
From: "Steven Webster" <[EMAIL PROTECTED]>
To: <flexcoders@yahoogroups.com>
Sent: Friday, August 05, 2005 11:56 AM
Subject: RE: [flexcoders] Cairngorm vs ARP
Hi Jesse,
I'll just pick up on some points here. My summary is simple however; the
design patterns and their interactions, and the implementations of the J2EE
concepts in the Flash ecosystem, are largely similar in Cairngorm and ARP.
I'd hate to try and do a summary of the differences between the 2
frameworks, as there are more similarities than differences.
| both were developed based on similiar ideas, but they both have different
goals.
I don't think I agree here ... the goals of a framework are to provide a
lightweight infrastructure upon which an application architecture can hang.
The goal of a microarchitecture (a design pattern based framework) is to
leverage design patterns that encapsulate proven and reusable solutions to
commonly recurring problems. That Cairngorm and ARP both provide
infrastructure for architecture, that they both leverage the same subset of
J2EE design patterns, and that they are both intended to provide a "modular,
scalable and reusable" architecture, suggests to me the goals are very
similar.
Cairngorm started life as a Flash application architecture, make no mistake
... that we have elected to "back the Flex" horse reflects our belief that
the applications that most merit the additional complexity of a
microarchitecture, are also going to merit a declarative programming
workflow and enterprise services that Flex offers. That Zorn will now lower
the barrier-to-entry significantly for the declarative development of MXML
and ActionScript based RIAs, fortifies our decision to focus on declarative
RIA development over timeline-based development. However, those that wish
to continue to use Cairngorm in a timeline environment can ... all we don't
recommend is how they structure their FLA, because people like you can make
better recommendations on that than we can :)
| ARP is in transition (in my opinion) right now. Aral, like the Cairngorm
team, is very
| respectful of the community's input, and as such has enlisted people on
the ARP
| Advistory Comittee to help steer it, along with everyone else on various
lists.
Again, I see that as analagous to the Cairngorm committee that was put
around the Cairngorm team; again, both frameworks are being driven by teams
of developers who are using the frameworks in their day to day development.
| ARP is meant to be lightweight. Since a lot of Flash apps are not always
as
| heavyweight as Flex apps, and have significantly shorter dev cycles,
over-OOP'ing
| something doesn't help. As such, ARP is light enough that you can not
only use just
| some of it, but if you had to, it'd scale well later if you added more
features to your
| app; case in point, scope creep.
ARP is no more or no less lightweight than Cairngorm. When we coined the
phrase "lightweight architecture" around Cairngorm, what we are describing
is the degree of prescription in how to use the architecture. Lightweight
means that it's skeleton without the muscle. Heavyweight frameworks offer
greater functionality, at the expense of greater prescription (be those XML
configuration files, or insisting that your view uses certain components,
etc).
That Cairngorm and ARP offer the exact same design patterns, the exact same
interactions between these design patterns, and the exact same freedom to
decide what to keep and what to drop, would suggest that no framework is
more lightweight than the other.
ARP assumes a form-based development model; there's an element of
prescription about the structure of the Flash UI (I've not really followed
what prescription, if any, is made about the Flex UI). Cairngorm offers or
asks for no such prescription in how the UI is developed. We offer
CairngormApplication as a tag for "getting started", but it's not a
necessity.
| dealing with. However, from a J2EE gents perspective, there is still much
to be
| further abstracted, so Cairngorm too helps in that arena. Some of those
from the Flash
| world have a hard time letting go, so one can see how ARP provides a nice
lighter
| weight alternative that still gives you the patterns you want, and
allowing you to keep
| the low-level control you're used too.
I'm not quite sure what features it is that you think Cairngorm is
abstracting, that makes it more heavyweight ? We don't ask people to expose
themselves to the details of Flash Remoting - Flex already provides a
significant abstraction in RemoteObject and WebService calls, so we leverage
off that.
If you mean the CairngormApplication.mxml tag, it's simply there as a
shortcut macro if you like, for those who always have an identical
Application.mxml on an application by application basis.
And remember "heavyweight == prescription", not flexibility and option...
| There are many ways, both technically, and design wise to handle data in
Flash. In
| Flex, it's clear: HTTPService, WebService, or RemoteObject, and each has a
pretty
| standard use; getting data for your Views. In Flash, the variety of scope
provides
| little common ground, so while you'll find a ModelLocator in Cairngorm,
you won't find
| one in ARP.
ModelLocator isn't a strategy for handling data services; the ModelLocator
pattern is not one of the Core J2EE patterns, but simply a practice that
emerged as we watched people using Cairngorm with Flex. If people start
building big apps with ARP and Flex, the same problem will arise, where
developers have to keep State on the client in a single place.
Again, in the interests of being as lightweight as possible, Cairngorm is
leveraging off Flex functionality, and the ModelLocator allows developers to
leverage data-binding correctly in their application.
I'll come to ViewHelpers in a second; but when developers are continually
calling setters on the view ("pushing data to the view") when building with
Flex, then they're missing out on all the value-add that databinding offers.
Databinding enables a more true MVC implementation, where the model (state)
*notifies* the view of changes, and the view listens for these changes to
update the user. ModelLocator isn't a strategy for data services, it's a
strategy to encourage developers to build MVC apps where the model notifies
the view, and not where the command tier is pushing data forcibly onto the
view (whether calling setters on forms, or abusing the convenience of
ViewHelpers).
| I have as of yet managed to get my head wrapped around ViewHelpers. In
Cairngorms'
| defense, I've seen some insane forms developed by Flex people, and as
such, managing
| pulling/putting data from them could benefit from them. Additionally,
from those
| coming from Tapestry, or any other HTML esque world where you try to hide
the actual
| implementation from the data, it makes sense.
View Helpers are *not* evil :-) Demonising a design pattern is evil :)
| In the Flash world, it doesn't make sense. You don't build big forms, you
build
| modular ones mainly because Flash isn't as easy as Flex is to make great
forms, and
| secondly, keep track of your View's in Flash, you're pretty close to the
details of how
| they are made, and as such, a few getter/setters seems like a HUGE
abstraction when in
| that perspective. As such, if a Command in ARP for example has little
problem deducing
| the data it needs to pull from a View; it just uses the getters since the
import
| statement is right there.
| I still cannot see, however, that as my forms got more complex and
innovative,
| justifying an additional layer of abstraction for data
removal/replacing... my Commands
| currently work just fine for that.
Remember a View Helper is a concept, not code. A View Helper is where there
is a solution to the problem of preparing/massaging/manipulating data for
the view.
In old-skool Flash days, we had projects where a large collection of nested
movie clips existed, and that the knowledge of the nesting of those movie
clips resided very much with the developer who implemented the UI.
So rather than a Command class have to know to do:
_root.mainScreen.addressBook.addressEntry.forename.text = result.forename;
The Command class could instead say:
AddressBookViewHelper.setForename( result );
Then, if the implementation of the view changed (ie a new movieclip was
inserted in the hierarchy) the Flash developer would change a *single* view
helper class (AddressBookViewHelper) and the RIA developer would be
insulated from that UI implementation decision.
You can't call that evil. You might have another strategy you prefer, but
you can't call all other strategies evil.
I mean, Flex FORMATTERS are specific implementations of the View Helper
pattern, manipulating the model (data) for the view.
Flash Forms made things a little simpler; as you say, provide some getters
and setters on your Flash forms, and call them from your command. That's a
great solution -- some are doing this in Flex as well, creating a
"code-behind" ActionScript file from which their Flex class extends. Not my
preference, but a definite solution to the same problem.
And you know what ... these are ALL implementations of a view helper. They
are different implementations of solutions to the same problem; how do we
insulate the application developer (the author of Commands) from the
implementation and layout structure of the view.
A reason I'm not a fan of the code-behind or getters/setters on forms, is
that it still requires a fine-grained knowledge of the UI (ie you need to
know which form/component to use to update the view). When you're building
Flex RIA with hundreds not tens of screens, you want to be able to update
multiple parts of the view with one piece of returned data, or you might
receive some complex object that needs to be fragmented to update several
portions of the view).
The ModelLocator solves this problem, and in the Cairngorm 0.99 docs we
discuss that developers should be cognisant of the ModelLocator, and should
leverage data-binding, and stick to using the ViewHelper when manipulating
the model for the view. Now, commands take responsibility for updating the
model with complex model objects, and individual views are able to pull
their data from the model by binding.
In this way, the fine grained view listens to the coarsely-grained model,
not the coarsely-grained model trying to set data on the finely-grained (and
likely to change) view.
| But, my opinions change everday as I learn more, so it may change
tomorrow.
Me too :)
| post-Zorn, and I did, I may look into alternatives such as AS2Lib &
Cairngorm, but for
| now, I enjoy the lightweight implementation of ARP, and it's use in Flex.
Finally, I'd not want to confuse Cairngorm and AS2Lib ... AS2Lib isn't a
framework, it's a suite of APIs; Cairngorm and ARP are as lightweight as
each other, which is no surprise given their common genealogy.
The bottom line for anyone evaluating ARP versus Cairngorm, I'd say this.
First -- understand WHY it is that you're considering embracing an
architectural framework. Don't embrace one because you think you have to,
or because you realise that other people building the kind of Flex apps that
you're building are using one. Understand what the problems you are facing
are, and then understand how a Flex framework helps you address those
problems.
Then, if you find yourself moving towards a framework, try to understand
exactly what the recurring problems each of the design patterns are trying
to address - the AS2.0 Dictionary chapter might be a good start for that:
http://www.richinternetapps.com/archives/000128.html
For anyone considering ARP and Cairngorm with Flex, I think I'd much rather
that people try to recognise the similarities in the solutions, than try and
drive a wedge between the frameworks and suggest that they are different in
aims, audience or implementation.
Apologies for the length of the email - but the View Helpers deserved
nothing less. :-)
Best wishes,
Steven
--
Steven Webster
Technical Director
iteration::two
This e-mail and any associated attachments transmitted with it may contain
confidential information and must not be copied, or disclosed, or used by
anyone other than the intended recipient(s). If you are not the intended
recipient(s) please destroy this e-mail, and any copies of it, immediately.
Please also note that while software systems have been used to try to ensure
that this e-mail has been swept for viruses, iteration::two do not accept
responsibility for any damage or loss caused in respect of any viruses
transmitted by the e-mail. Please ensure your own checks are carried out
before any attachments are opened.
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
Yahoo! Groups Links
------------------------ Yahoo! Groups Sponsor --------------------~-->
<font face=arial size=-1><a
href="http://us.ard.yahoo.com/SIG=12hbtm209/M=362329.6886308.7839368.1510227/D=groups/S=1705007207:TM/Y=YAHOO/EXP=1123266112/A=2894321/R=0/SIG=11dvsfulr/*http://youthnoise.com/page.php?page_id=1992
">Fair play? Video games influencing politics. Click and talk back!</a>.</font>
--------------------------------------------------------------------~->
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
