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
