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

Marcelo de Moraes Serpa celoserpa at gmail.com
Thu Jan 4 06:34:36 EST 2007 

@Stephan: Awesome! Thank you for taking your time to build a sample! I will
study it when I get home and let you know of any comments/suggestions :D

@Tim: LOL... my brain is also melting, but nothing better than a good
discussion to clear things out, cooling our brain :). Thank you for the
comprehensive reply and for being so helpful Tim, this will surely help
shape pixlib's future (and our future as well!). As for Mike's example, I
did study it again (it is impressive how you can look again to something and
see it in a totally different way - you see, at the time I first saw it, I
had zero experience with pixlib, and even though I thought I understood the
overall way Mike structured the RIA, I was wrong) and I wonder why Mike said
it was a "Hot plug and play view"? It's not totally "plug and play"
(SushiListUI is present on the main Application's class...).. I guess that
the main purpose of SushiListUI is to act like a container for the other
views, so, adding other views ("states" as he put it) would be the work of
only modifying the SushiListUI class and recompile views.swf, right?

Btw, where is Mike? Haven't seen him lately on this list...

Let's keep pixlibing... my brain asks for more x)

Marcelo.

On 1/4/07, henrik weber <hw at freemind-design.de> wrote:
>
>  tough time-management ;)
> wish you luck! keep us informed how it worked for you and
> where you saw possible pitfalls...
>
> cheers!
>
> henrik
>
> Tim Will wrote:
>
> Thanks Henrik! :)
> I have only 2 days for my next project...I'm going to try PixLib for it -
> hopefully it can save me!
> I will try to make notes as I go.
>
> -tim.
>
>
> On 1/3/07, henrik weber <hw at freemind-design.de> wrote:
> >
> > hi tim,
> >
> > thank you very much for your explanations! :D i really appreciate  the
> > time you invested in it...
> > <snip>Now you may wonder, why is this useful</snip> was a good one and
> > pushed me in the
> > right direction; i think i understand what you're trying to say...
> > hopefully ;)
> > anyhow: examples would be very welcome, but take your time...
> >
> > greetz!
> >
> > henrik
> >
> > Tim Will wrote:
> >
> >  Hey Marcelo,
> > You've got the right idea there!
> > Now keep in mind that there is nothing to stop you from compiling
> > classes into your view swfs (in fact that is sort of the reason for a plugin
> > - so the plugin can do whatever in any way)
> > The pluginHelper is a manager, very much the same as MovieClipHelper,
> > except it implements an Interface.  As you say, it sits in the core-engine.
> > The interface is designed to form a contract so that only Plugins can be
> > loaded in.  This makes sure that all plugins have the methods necessary to
> > update themselves following system-level events.  Basically, the
> > PluginHelper is all about forming an API between plugins and the Core engine
> > - that is its prime function.
> > The MovieClipHelper gives the following functionality;
> > 1. Can broadcast events, add or remove listeners
> > 2. Can define the view, either by movieClip or by GraphicLib (which I
> > think is so cool :) )
> > 3. Can associate itself with a unique identifying name
> > 4. "Resolve" function can tell if a movieClip is associated with the
> > MovieClipHelper
> > 5. Some others, such as setting visible or not visible, moving, setting
> > size, etc.
> > Now you may wonder, why is this useful - a movieClip can do most of
> > these things by itself.  True...but in the case of a MovieClip, all these
> > properties belong to the MovieClip alone - if we remove the MovieClip, all
> > this information is lost.  This approach favors inheritance over composition
> > (note there is no way to instantiate a movieclip with "new").
> > With the MovieClipHelper (or ViewHelper) this information is all
> > associated with the MCH rather than the MovieClip itself.  If we
> > destroy/alter/remove the movieclip, its state is preserved by the MCH
> > associated with it - this favors composition.
> > In fact, many things about PixLib seem to be geared towards favoring
> > composition (even though natively Flash seems to encourage inheritance...I
> > think most of us started with class SomeClass extends MovieClip right?).
> > This is a very good thing about Pixlib, as composition is more
> > versatile.  Imagine what you can do with it!  You could; unregister the MCH
> > and register it under a new name to change it's logic.  You can change its
> > graphics by re-loading its GraphicLib or by setting the "view" property to a
> > different MovieClip.  And the really nice thing is you can always identify
> > it by the MovieClipHelper.getMovieClipHelper("some name") method call.
> > In this way, the view, logic, even what models its subscribes to, all become
> > very interchangeable.  Rockin'.
> > I can't speak for ARP too much, I saw it and thought it was cool but
> > seemed very much geared to RIAs, whereas I'm doing games, online
> > advertising, sites, social networking etc.
> > I'm working on some examples, but my schedule is hectic just now.  Also,
> > I haven't yet decided if PluginHelper should be a singleton.  I think it
> > could be unless we are loading in multiple plugins at one time.......what do
> > you think?
> > Hopefully this is helpful...
> > -tim.
> >
> >
> >
> > On 1/2/07, Marcelo de Moraes Serpa <celoserpa at gmail.com > wrote:
> > >
> > > 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
> > > >
> > > >
> > > >
> > >
> > > _______________________________________________
> > > Pixlib mailing list
> > > Pixlib at osflash.org
> > > http://osflash.org/mailman/listinfo/pixlib_osflash.org
> > >
> > >
> > >
> >  ------------------------------
> >
> > _______________________________________________
> > Pixlib mailing list
> > Pixlib at osflash.orghttp://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/20070104/b5ccaf25/attachment-0001.htm

More information about the Pixlib mailing list