Re: [Flashcoders] FlashVars + OOP, Best Practices?
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'll be
available right from the beginning. I know there are some who will want to
argue that this is a dependency but that could be similar to arguing that
the MovieClip is a dependency -- it's a documented and supported feature)
Tyler
On 6/7/06, Tyler Wright <[EMAIL PROTECTED]> wrote:
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 easy as possible -- all in one place.
With the dynamic Singleton if the naming of the specific FlashVars change
you still have to search through all of your code and update those
references. If, however, your main Application class (specific to your app)
should take those variables and store them by some application-specific
name, you now have a single place for all of your classes to access and one
place to make changes should a backend developer decide mid-project to mix
things up. Singleton or any class are instantly useless as soon as they
perform exactly as an anonymous object (usually involving dynamic and
resolve). I agree that FlashVars should be limited to receiving config
information only at which point an application can gather further
information if needed.
It needs to make sense, not just seem more correct. OOP is a tool for
change and reuse of code. It was never meant to be something for blind
faith.
The suggestions I have for your current class:
1) create a hash table coded to the specific FlashVar class for your
particular app. It should have the FlashVar name as well as a reserved name
given for application use. These can be the same, but if the FlashVar name
were to change it could be updated here and the application would continue
using the value by the app name.
ex.
var hashVars =
{
fv_url:"baseURL",
fv_uid:"userID"
}
2) (what you've got with naming convention is really good, good standard
to have, so this is just an alternative, not a better way) have the class
initiate from a static constructor (so it will happen before frame1 and
before everything really gets going). At this point you can scrub _level0
for each var in your hash table (everything that isn't a MovieClip,
TextField, Button, or the $version property will be a FlashVars). You can
then store them and delete them from _level0 promptly. This will help your
class not be dependant on an arbritrary naming convention.
Tyler
On 6/6/06, Morten Barklund <[EMAIL PROTECTED]> wrote:
>
> 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 only. Move this into your settings class if you need it.
>
> But it's private anyways. Is made to be used by subclasses.
>
> > 3. Use composition in the SomeSettingsClass class rather than
> > inheritance since this isn't an 'is a' relationship.
>
> That would require more code, and the ability to overturn dynamicness
> through inheritance makes this seem preferable to me.
>
> And I actually find the relationship as being an "is a" - as the
> settingsclass would be used only for FlashVars-variables. Other settings
> (read from XML and more) could of course be read in as well, in which
> case composition would be preferable.
>
> But I do follow your concerns on all three matters.
>
> > It's also worth noting that the Flex 2 framework has a nice method of
> > abstracting FlashVars via the Application.application.parametersarray.
>
> Those will be the days... :)
>
> --
> Morten Barklund
> ___
> Flashcoders@chattyfig.figleaf.com
> 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
>
___
Flashcoders@chattyfig.figleaf.com
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
Re: [Flashcoders] FlashVars + OOP, Best Practices?
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 easy as possible -- all in one place. With the
dynamic Singleton if the naming of the specific FlashVars change you still
have to search through all of your code and update those references. If,
however, your main Application class (specific to your app) should take
those variables and store them by some application-specific name, you now
have a single place for all of your classes to access and one place to make
changes should a backend developer decide mid-project to mix things up.
Singleton or any class are instantly useless as soon as they perform exactly
as an anonymous object (usually involving dynamic and resolve). I agree that
FlashVars should be limited to receiving config information only at which
point an application can gather further information if needed.
It needs to make sense, not just seem more correct. OOP is a tool for change
and reuse of code. It was never meant to be something for blind faith.
The suggestions I have for your current class:
1) create a hash table coded to the specific FlashVar class for your
particular app. It should have the FlashVar name as well as a reserved name
given for application use. These can be the same, but if the FlashVar name
were to change it could be updated here and the application would continue
using the value by the app name.
ex.
var hashVars =
{
fv_url:"baseURL",
fv_uid:"userID"
}
2) (what you've got with naming convention is really good, good standard to
have, so this is just an alternative, not a better way) have the class
initiate from a static constructor (so it will happen before frame1 and
before everything really gets going). At this point you can scrub _level0
for each var in your hash table (everything that isn't a MovieClip,
TextField, Button, or the $version property will be a FlashVars). You can
then store them and delete them from _level0 promptly. This will help your
class not be dependant on an arbritrary naming convention.
Tyler
On 6/6/06, Morten Barklund <[EMAIL PROTECTED]> wrote:
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 only. Move this into your settings class if you need it.
But it's private anyways. Is made to be used by subclasses.
> 3. Use composition in the SomeSettingsClass class rather than
> inheritance since this isn't an 'is a' relationship.
That would require more code, and the ability to overturn dynamicness
through inheritance makes this seem preferable to me.
And I actually find the relationship as being an "is a" - as the
settingsclass would be used only for FlashVars-variables. Other settings
(read from XML and more) could of course be read in as well, in which
case composition would be preferable.
But I do follow your concerns on all three matters.
> It's also worth noting that the Flex 2 framework has a nice method of
> abstracting FlashVars via the Application.application.parameters array.
Those will be the days... :)
--
Morten Barklund
___
Flashcoders@chattyfig.figleaf.com
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
___
Flashcoders@chattyfig.figleaf.com
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
Re: [Flashcoders] FlashVars + OOP, Best Practices?
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 only. Move this into your settings class if you need it. But it's private anyways. Is made to be used by subclasses. 3. Use composition in the SomeSettingsClass class rather than inheritance since this isn't an 'is a' relationship. That would require more code, and the ability to overturn dynamicness through inheritance makes this seem preferable to me. And I actually find the relationship as being an "is a" - as the settingsclass would be used only for FlashVars-variables. Other settings (read from XML and more) could of course be read in as well, in which case composition would be preferable. But I do follow your concerns on all three matters. It's also worth noting that the Flex 2 framework has a nice method of abstracting FlashVars via the Application.application.parameters array. Those will be the days... :) -- Morten Barklund ___ Flashcoders@chattyfig.figleaf.com 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
Re: [Flashcoders] FlashVars + OOP, Best Practices?
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 static methods/properties instead of singleton. Gets rid of '.getInstance().' cruft. 2. Remove the setVar() method since these properties really should be read only. Move this into your settings class if you need it. 3. Use composition in the SomeSettingsClass class rather than inheritance since this isn't an 'is a' relationship. It's also worth noting that the Flex 2 framework has a nice method of abstracting FlashVars via the Application.application.parameters array. Cheers, Steve -- Steve Webster Head of Development Featurecreep Ltd. http://www.featurecreep.com 14 Orchard Street, Bristol, BS1 5EH 0117 905 5047 ___ Flashcoders@chattyfig.figleaf.com 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
RE: [Flashcoders] FlashVars + OOP, Best Practices?
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:
//--
class com.kurst.utils.flashVars {
static private var __flashVars:flashVars
static function getVar(name:String):String{
return getInstance().variables[name];
}
static function getVars( ):Object{
return getInstance().variables;
}
static public function getInstance(Void):flashVars {
if( __flashVars == undefined ){
__flashVars = new flashVars();
__flashVars.findVars();
}
return __flashVars;
}
private var variables:Object
function flashVars(){
variables = {};
}
public function findVars ():Void{
for ( var i in _level0 ) {
if ( ( i.substring(i.length - 4 ,i.length) ) ==
"_prm" ) {
__flashVars.variables[ i.substring(0
,i.length - 4) ] = _level0[i];
}
}
}
}
//--
- karim
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Zárate
Sent: 06 June 2006 10:25
To: Flashcoders
Subject: [Flashcoders] FlashVars + OOP, Best Practices?
Hi all,
We all know FlashVars and how useful they are. My question is if is there a
"Best practices" document/post/info somewhere. I'm pretty sure I don't want
to access them with _root.flashvarName. As I am working with MTASC I always
look for them in the MovieClip passed as a parameter to the
main(m:MovieClip) method.
Then, I always prefix them with "fv_". I do that to easily recognise them in
the code.
And last but not least I'm now thinking in forcing me to access them trough
a singleton FlashVarsClass, just to encapsulate them in case Adobe change
the way we should FlashVars. Do we know if this is going to change in Player
9? I've searched Adobe labs, but there's no too much info on this subject.
Any ideas/thoughts/comments would be appreciated.
Cheers : )
ps: Probably this seems overdesign for too many people... insults welcome to
:P
--
Zárate
___
Flashcoders@chattyfig.figleaf.com
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
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.1/355 - Release Date: 02/06/2006
___
Flashcoders@chattyfig.figleaf.com
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
Re: [Flashcoders] FlashVars + OOP, Best Practices?
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). And last but not least I'm now thinking in forcing me to access them trough a singleton FlashVarsClass, just to encapsulate them in case Adobe change the way we should FlashVars. As do I. 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/ -- Morten Barklund - Lead Developer - TBWA\Play ___ Flashcoders@chattyfig.figleaf.com 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
RE: [Flashcoders] FlashVars + OOP, Best Practices?
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 Sent: 06 June 2006 10:25 To: Flashcoders Subject: [Flashcoders] FlashVars + OOP, Best Practices? Hi all, We all know FlashVars and how useful they are. My question is if is there a "Best practices" document/post/info somewhere. I'm pretty sure I don't want to access them with _root.flashvarName. As I am working with MTASC I always look for them in the MovieClip passed as a parameter to the main(m:MovieClip) method. Then, I always prefix them with "fv_". I do that to easily recognise them in the code. And last but not least I'm now thinking in forcing me to access them trough a singleton FlashVarsClass, just to encapsulate them in case Adobe change the way we should FlashVars. Do we know if this is going to change in Player 9? I've searched Adobe labs, but there's no too much info on this subject. Any ideas/thoughts/comments would be appreciated. Cheers : ) ps: Probably this seems overdesign for too many people... insults welcome to :P -- Zárate ___ Flashcoders@chattyfig.figleaf.com 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 ___ Flashcoders@chattyfig.figleaf.com 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
[Flashcoders] FlashVars + OOP, Best Practices?
Hi all, We all know FlashVars and how useful they are. My question is if is there a "Best practices" document/post/info somewhere. I'm pretty sure I don't want to access them with _root.flashvarName. As I am working with MTASC I always look for them in the MovieClip passed as a parameter to the main(m:MovieClip) method. Then, I always prefix them with "fv_". I do that to easily recognise them in the code. And last but not least I'm now thinking in forcing me to access them trough a singleton FlashVarsClass, just to encapsulate them in case Adobe change the way we should FlashVars. Do we know if this is going to change in Player 9? I've searched Adobe labs, but there's no too much info on this subject. Any ideas/thoughts/comments would be appreciated. Cheers : ) ps: Probably this seems overdesign for too many people... insults welcome to :P -- Zárate ___ Flashcoders@chattyfig.figleaf.com 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
