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
