[Pixlib] notes online, re. plugin/module structure

Tue Jan 2 11:14:53 EST 2007

Great Tim! Thanks for your effort! Together we will make pixlib a unbeatable
framework for AS2, I'm sure... this is just what pixlib needs: clever
discussions and documentation (and a great community, something we already
have !) :)

As might have noted, I'm also **very** interested on modular application
techniques (particulary how to implement them with pixlib :).

PixLib favors the separation of business logic from the view logic with its
MovieClipHelper approach. I must stay it was a little difficult for me to
graps this concept at first, becouse I was so used to ARP's pure MovieClip
views...

With ARP, I had several SWF's, one for each "Form" of the application. It
was a rough "plug-in" system, but it worked. All the classes related to this
SWF would get compiled into this SWF.

And when I get to this point, I get confused on how to implement such thing
with pixlib, mainly becouse of this separation of the MovieClipHelper from
the "graphics SWF".

What I didn't understand yet, is the role of MovieClipHelper  (in the case
of the plug-in framework, "PluginHelper" if I understood right) when it
comes to the plug-in architecture we've been discussing. From what I saw by
reading the code, the plug-in is a MovieClip subclass and its "PluginHelper"
sits on the "core" SWF. It seems also that the PluginHelper does not have
any logic in it (contrary from the classic utilization of MovieClipHelper),
instead the logic is implemented on the plugin class itself (the one that
extends MovieClip), so we wouldn't have any "PluginHelper" subclasses,
right?

If anyone could helpme to understand these concepts, I would be very happy
indeed :)

Cheers and happy new year everyone!

Marcelo.

On 1/2/07, Zameer Rehmani <zrehmani at gmail.com> wrote:
>
> Hey Tim,
> Yeah I know a lot of people moved into flash development through their
> initial romance with flash design and animations.  I walked the same path
> and its so heartening to hear you traversed the same path. :-)  Yeah I find
> the lack of Flash Awareness at workplace very annoying also but I think its
> changing as people learn about this new technology and hopefully that will
> begin to reflect in titles and roles as well.  For now, I guess the
> responsibility rests with the developer as well to build the niche for
> themselves.  I am very clearly the defacto architect in our team which is
> not the title of my position but its understood that's what enjoy the most.
> I still enjoy animations and do quite a bit of it, mostly algorithm and code
> based tweenings ( I stopped doing timline tweens ages ago!) but I prefer the
> architect part.  And yes, I agree with you on the plugin / modular approach
> in flash development; its basically about delegating responsibilities to the
> right people for the right job.
>
> For the API, I think two most important methods implementation would be
> activate / deactivate or setActivate / setDeactivate something along that
> line.  And events to match that would be
> onPluginActivatedEVENT/onPluginDeactivatedEVENT again something to that
> effect.  Sometimes I also think may be you want to build the UI before you
> activate it at a later stage.  So perhaps something like buildUI and
> relevant event could be onUIBuiltEVENT.
>
> At least that's my thought for...I have to run now..late for work!!
>
> Zameer
>
>
> On 1/1/07, Tim Will < thedigitalartist at gmail.com> wrote:
> >
> > Hey Zameer,
> > It is amazing to me how often I hear this in the Flash community
> > (designers who are also developers or have moved into developing).  It is
> > actually pretty rare I think, outside of Flash.  My experience is very
> > simillar, coming from fine arts, to graphic design, to coding, then
> > developing, and now development architecture and workflow.
> > What I have found is that companys have not learned there are many kinds
> > of "Flash guys".  You find a motion graphics specialist being wedged into
> > the role of architect - a role which makes them unhappy, forces them to work
> > long hours, with many revisions and in the end no one but them can touch the
> > files.  They are condemned to keep going back to those projects forever,
> > when they would rather move on to another one.
> > My goal in 2007 is to eliminate this from the projects I work on - to
> > give all the benefits of OOP to designers, motion graphics guys, UI
> > developers, while making it almost invisible to them.  It is very freeing to
> > hand a piece of a project to one of these guys and say 'go nuts!'.  Then
> > they hand it back, you plug it in, and it 'just works'.
> > It sounds like Francis has achieved this, and that is encouraging! :)
> >
> > Now lets think about the API required to achieve this.  If we are using
> > an Interface to regulate the API for communication from the core to the
> > plugins, what sort of methods need to be detailed by the Interface?  Well,
> > Francis has suggested it is better to broadcast system events rather than
> > call methods directly on the plugin - so in that case, very few methods need
> > to be outlined in the Interface.
> >
> > So what kind of system events need to be broadcast I wonder?  Probably
> > not too many, something to send the plugin into its various states (say,
> > "enabled", "disabled", "intro", "exit", "display", "hide").
> > Then we also need system events for persistent data the plugin needs to
> > know about.
> >   As an example, if we have a navigation at the core engine that is used
> > to load in mini-game plugins, maybe they need to know about the score that
> > has accumulated as the user switches between mini-games.  Perhaps the goal
> > is to accumulate 500 points total.  Each mini-game should display the total
> > the user has scored for that game, and also their total score for all games.
> >
> >
> > In that case, at some point the core must broadcast a dynamic event such
> > as "setscore" (perhaps after hearing an "onIntroComplete" event from the
> > plugin's _global.__DISPATCH).  Every plugin is required to have a 'setScore'
> > method....so I think that should be included in the Interface.
> > Now, why a broadcast from the core?  Why not just call the setScore
> > method on the plugin?  Well, maybe we want to have two, three or five
> > plugins onstage at one time - maybe the other games go to their "disabled"
> > state when the user is not playing them.  With the core broadcasting a
> > system event, all plugins could continue to update their scores as the user
> > played any game.  If we were calling methods directly, we would have to
> > write some kind of hacky 'for....in' routine to call the setScore method of
> > all plugins onstage.
> >
> > What do you guys think??
> >
> > -tim.
> >
> >
> > On 1/1/07, Zameer Rehmani < zrehmani at gmail.com> wrote:
> >
> > > Yeah I totally agree.  I enjoy motion graphics with my background in
> > > graphic design rather than computer science but I also really appreciate
> > > good logic and architecture.  And I love OOP.  Professionally, I have moved
> > > away from graphic design completely; still do it on pro-bono basis but at
> > > work I am a coder.  I also enjoy the site design and architect part more
> > > than the motion graphics.  In our team, I set up the site, the diagrams, the
> > > logic and mostly delegate the cool motion graphics part to other developers
> > > who live for that stuff.  What I love about Francis solution is that it
> > > separates the logic and design, allowing designers complete freedom and
> > > independence to design their uis that can be plugged into the main system
> > > seamlessly.  I think your solution addresses the need for two way
> > > communication that is necessary in most situation.  May be Francis can leave
> > > a few clues and ideas how he achieves the same in his framework.
> > > ciao,
> > > Zameer
> > >
> > > _______________________________________________
> > > Pixlib mailing list
> > > Pixlib at osflash.org
> > > http://osflash.org/mailman/listinfo/pixlib_osflash.org
> > >
> > >
> > >
> >
> > _______________________________________________
> > Pixlib mailing list
> > Pixlib at osflash.org
> > http://osflash.org/mailman/listinfo/pixlib_osflash.org
> >
> >
> >
>
> _______________________________________________
> Pixlib mailing list
> Pixlib at osflash.org
> http://osflash.org/mailman/listinfo/pixlib_osflash.org
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/pixlib_osflash.org/attachments/20070102/a6509203/attachment-0001.htm