See reply inline..
----- Original Message -----
From: "Marcelo de Moraes Serpa" <[EMAIL PROTECTED]>
To: "Flashcoders mailing list" <[email protected]>
Sent: Wednesday, November 08, 2006 1:51 PM
Subject: Re: [Flashcoders] Q:Framework ARP vs PixLib
> Hi Muzak,
>
> Can you provide some more details on these 2 statements?
>>
>> - found arp to be somewhat limited and unflexible
>> - It goes far beyond ARP, no doubt
>
>
> ARP was no doubt the pioneer in introducing design patterns development into
> flash apps. However, its MVC model is not what I would call the ideal, not
> when you take into account the decoupling between the classes.
>
> Pixlib has two MVC models you can choose: a "strict" one and a
> frontcontroller based one, similar to arp/cairngorm.
>
> The original arp didn't have a EventBroadcaster nor the concept of system
> events.
True, but it doesn't need to, as there is already an EventDispatcher that comes
with Flash.
It does make a distinction between View and System events though:
<quote>
Both types of events are broadcast from Forms within your View, however the
objects interested in and listening for the events
are different.
System Events are events that concern the application. The Application
Controller listens for System Events and maps them to
Commands.
In most cases the Commands either by themselves or using Business Delegates
will cause the execution of business logic either on
the client or, more commonly as part of a remote service.
View Events, by contrast, only concern the View. Business logic, especially
remote business logic, is not triggered in response
to View Events.
Forms within the View listen for View Events either on themselves, on their
components or on other forms.
</quote>
But since ARP doesn't provide its own Event system, it kinda leaves it up to
the developer to work out which events are View/System
events.
Even though ARP is now open source it originally wasn't, and was meant to be
used with the Flash IDE and v2 components framework, so
assumed that you'd use the existing mx.events.EventDispatcher. It is also meant
to be lightweight, so using
mx.events.EventDispatcher makes sense.
> To make views downloadable at runtime I had to modify significantly
> the way it worked. Also, the lack of a ModelLocator (introduced on recent
> versions of ARP) and the coupling between commands and views were things I
> really didn't like about ARP
Yup, the coupling between views and commands is something most people don't
like about it, including me ;-)
This has been discussed on the ARP mailing list quite a few times and solutions
have been provided as well.
I think the ModelLocator has been around for quite some time now.
There's a simple one in the svn trunk, and there's another floating around by
Christophe Herreman that allows for databinding and
that kind of stuff.
> Pixlib makes it easy to load and locate views
> anywhere in your application through MovieClipHelper and GraphicLibLocator
> classes, and has a very nice Model and ModelLocator class. Not to mention
> the other usefull packages and classes it provides. It has been designed
> from the ground up to be powerful and flexible.
Agreed, ARP doesn't make it easy to use external swf's as views, meaning it
doesn't provide anything to achieve/handle this.
I do remember someone posting a solution for this on the ARP list as well.
Can't remember who though.. (can't find the thread right
now).
>
> Take a look at www.deja-vue.net, at the Sushi service application ... this
> was the article that conviced me to "switch" to pixlib.
>
For those interested, the sushi service app is here:
http://www.deja-vue.net/blog/2006/05/25/actionstep-plugin-view-pixlib-mvc-frontcontroller-remoting-sushi-service/
Thanks for sharing your thoughts.
regards,
Muzak
_______________________________________________
[email protected]
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
