Oops, I didn't read your full article. You solve those problems with
your extend
FlashVars suggestion! Singleton still doesn't make sense in this situation.
If you make the class a static that automatically parses _level0 you'll be
set (FlashVars will never be found anywhere but _level0 and they'l
I never really understood how making an anonymous object and it's properties
into a dynamic class suddenly made it object oriented. Singleton especially
seems to be a vice for that type of thing.
The reason you would abstract the FlashVars is to 1) avoid naming conflicts
and 2) to make changes as
Hi Steve,
1. Use static methods/properties instead of singleton. Gets rid of
'.getInstance().' cruft.
Well. In this case I prefer it used as a singleton - don't know why
really, but it just seems more correct to me.
2. Remove the setVar() method since these properties really should be
read
Morton,
I've just (after reading your mail) blogged[1] on the way, that I
normally do this. Please read this for my ideas of OOP-ness and
best practices on this matter. :)
[1] http://www.barklund.org/blog/2006/06/06/flashvars-and-as2/
Nice class. The only things I'd change are:
1. Use st
Ya, I do something similar, its quite handy.
all my flashVars have a "_prm" suffix. I use a singleton class which scans
the root and looks for all values with that suffix. So its as OOP'd as
possible. I've found this quite usefull. Here is the code:
//
Hi Zárate,
We seem to agree on a lot of points here. :)
As I am working with MTASC I always look for them in the MovieClip
passed as a parameter to the main(m:MovieClip) method.
As do I.
Then, I always prefix them with "fv_". I do that to easily recognise
them in the code.
As do I (almost
When using flashVars, one of my rules of thumb is to use as few as possible.
Indeed, only as many as is needed to redirect flash to attaining all the other
external variables via other means.
Lee
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zárate
7 matches
Mail list logo
