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