[Flashcoders] Understanding dynamic classes
Since we are in the understanding mode, I want to throw a question out
there.
Las week I made a component similar to the radio button component. While I
was working on this I requested help understanding the way the component
works. Eric (ericCD) suggested making a manager class:
--
Make a manager class that basically allows objects to register with it, and
then have it do what you want it to do. It can dispatch events and also
enable/disable members of the group.
-edolecki
--
I searched all over trying to find a way to incorporate his comments into my
component. I finally gave up and created a global variable to track my
buttons (actually it was a variable talking to _root).
Now since people are talking _globals I figure I would throw this out there.
Morten commented earlier:
--
I can make the same, now it's just OOP:
dynamic class APP {}
--
My question is, is that what Eric was refereeing to? And if that is what he
was referring to what would be the best way to implement such functionality?
All I was trying to achieve was to have each component track itself and
letting know all the components in the stage which one was being selected
and viceversa.
TIA
.helmut.
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Understanding dynamic classes
On Feb 1, 2006, at 7:00 PM, Helmut Granda wrote: Las week I made a component similar to the radio button component. While I was working on this I requested help understanding the way the component works. Eric (ericCD) suggested making a manager class: In a general sense, the concept is to make a class who's responsibility it is to maintain your buttons. There are a lot of ways to go about this. Usually, the manager is a singleton, and generation of the button instances may or may not be within its responsibility as well. But the gist is this... create the manager. Give it a property which is an array to hold your buttonObjects. When you create a new button, ask the manager to add a reference to it in that array. When you delete a button (probably through a function in the manager), remove it from the array. When you select a button, the manager can cycle through the array as a loop, deselecting all the other buttons. So, the manager might have functions for creating buttons, deleting buttons, selecting or deselecting buttons, returning the current selected button, and so on. One manager instance, many button instances. Once you get going with manager objects, you'll find uses for them almost anytime you have multiple instances of a class. And no, as long as the manager is pre-defined with an array to hold your button references, it does not need to be a dynamic class. The reason that was cited as an alternative to _globals is that dynamic classes can have new properties defined at runtime. HTH. -- Troy RPSystems, Ltd. http://www.rpsystems.net ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Understanding dynamic classes
Troy, thanks for such a great explanation. I had the same idea I just cant wrap it around my head in programming termns. For example if I have a property (array) inside a class it must be public so other intances of the object I create can access that property and they can write to it? And if that is true, how would I avoid having the property re-assigned (deleted or set back to its default value)? I guess here is where I have to have an if statement that checks if the property (array) already has values just push the next values into it. Would you say Im in the right track? Thanks again for the explanation. ...helmut Troy Rollins wrote: On Feb 1, 2006, at 7:00 PM, Helmut Granda wrote: Las week I made a component similar to the radio button component. While I was working on this I requested help understanding the way the component works. Eric (ericCD) suggested making a manager class: In a general sense, the concept is to make a class who's responsibility it is to maintain your buttons. There are a lot of ways to go about this. Usually, the manager is a singleton, and generation of the button instances may or may not be within its responsibility as well. But the gist is this... create the manager. Give it a property which is an array to hold your buttonObjects. When you create a new button, ask the manager to add a reference to it in that array. When you delete a button (probably through a function in the manager), remove it from the array. When you select a button, the manager can cycle through the array as a loop, deselecting all the other buttons. So, the manager might have functions for creating buttons, deleting buttons, selecting or deselecting buttons, returning the current selected button, and so on. One manager instance, many button instances. Once you get going with manager objects, you'll find uses for them almost anytime you have multiple instances of a class. And no, as long as the manager is pre-defined with an array to hold your button references, it does not need to be a dynamic class. The reason that was cited as an alternative to _globals is that dynamic classes can have new properties defined at runtime. HTH. -- Troy RPSystems, Ltd. http://www.rpsystems.net ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] Understanding dynamic classes
So far in AS2 Development I have not found a case yet to use Dynamic Classes. Has anyone come across an essential use for a Dynamic Class while developing an RIA, besides laziness. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Helmut Granda Sent: Thursday, 2 February 2006 2:14 PM To: Flashcoders mailing list Subject: Re: [Flashcoders] Understanding dynamic classes Troy, thanks for such a great explanation. I had the same idea I just cant wrap it around my head in programming termns. For example if I have a property (array) inside a class it must be public so other intances of the object I create can access that property and they can write to it? And if that is true, how would I avoid having the property re-assigned (deleted or set back to its default value)? I guess here is where I have to have an if statement that checks if the property (array) already has values just push the next values into it. Would you say Im in the right track? Thanks again for the explanation. ...helmut Troy Rollins wrote: On Feb 1, 2006, at 7:00 PM, Helmut Granda wrote: Las week I made a component similar to the radio button component. While I was working on this I requested help understanding the way the component works. Eric (ericCD) suggested making a manager class: In a general sense, the concept is to make a class who's responsibility it is to maintain your buttons. There are a lot of ways to go about this. Usually, the manager is a singleton, and generation of the button instances may or may not be within its responsibility as well. But the gist is this... create the manager. Give it a property which is an array to hold your buttonObjects. When you create a new button, ask the manager to add a reference to it in that array. When you delete a button (probably through a function in the manager), remove it from the array. When you select a button, the manager can cycle through the array as a loop, deselecting all the other buttons. So, the manager might have functions for creating buttons, deleting buttons, selecting or deselecting buttons, returning the current selected button, and so on. One manager instance, many button instances. Once you get going with manager objects, you'll find uses for them almost anytime you have multiple instances of a class. And no, as long as the manager is pre-defined with an array to hold your button references, it does not need to be a dynamic class. The reason that was cited as an alternative to _globals is that dynamic classes can have new properties defined at runtime. HTH. -- Troy RPSystems, Ltd. http://www.rpsystems.net ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Understanding dynamic classes
On Feb 1, 2006, at 10:23 PM, Bjorn Schultheiss wrote: Has anyone come across an essential use for a Dynamic Class while developing an RIA, besides laziness. Not if you go and rule out the number one reason I've done it just like that. ;-) -- Troy RPSystems, Ltd. http://www.rpsystems.net ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Understanding dynamic classes
On Feb 1, 2006, at 10:14 PM, Helmut Granda wrote: For example if I have a property (array) inside a class it must be public so other intances of the object I create can access that property and they can write to it? And if that is true, how would I avoid having the property re-assigned (deleted or set back to its default value)? I guess here is where I have to have an if statement that checks if the property (array) already has values just push the next values into it. Would you say Im in the right track? Mostly. Typically, the manager itself would have a function to instantiate the button. But even if you don't go that route, you would probably use a setter method. Which (from the button's perspective) might look something like: buttonManager.addButton(this); And then the button manager's function would receive that reference, perhaps loop through the array to be sure it isn't already there, and if not, add it with a array.push More clear? -- Troy RPSystems, Ltd. http://www.rpsystems.net ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Understanding dynamic classes
Troy, Lots of great advise, I felt for a minute I had it but then all of the sudden everything faded away... Where I get confused is when I have to pass the reference from the button to the manager function. All the methods come from the same class? for a minute I thought I needed 2 classes (1 to initiate the button, 2 to handle the references of the buttons). Thanks for your advice, Im going to start playing with this great ideas. Helmut. Troy Rollins wrote: On Feb 1, 2006, at 10:14 PM, Helmut Granda wrote: For example if I have a property (array) inside a class it must be public so other intances of the object I create can access that property and they can write to it? And if that is true, how would I avoid having the property re-assigned (deleted or set back to its default value)? I guess here is where I have to have an if statement that checks if the property (array) already has values just push the next values into it. Would you say Im in the right track? Mostly. Typically, the manager itself would have a function to instantiate the button. But even if you don't go that route, you would probably use a setter method. Which (from the button's perspective) might look something like: buttonManager.addButton(this); And then the button manager's function would receive that reference, perhaps loop through the array to be sure it isn't already there, and if not, add it with a array.push More clear? -- Troy RPSystems, Ltd. http://www.rpsystems.net ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Understanding dynamic classes
On Feb 2, 2006, at 12:24 AM, Helmut Granda wrote: Where I get confused is when I have to pass the reference from the button to the manager function. All the methods come from the same class? for a minute I thought I needed 2 classes (1 to initiate the button, 2 to handle the references of the buttons). The point is, you can do it either way (as well as a few others) - but ultimately the manager needs a reference of the button object to work with. You can instantiate the buttons from within the manager, or outside the manager, whichever way your mind, and program design tell you to go. For instance, if you have a class bound to a UI object, and are placing them on stage by drag and drop, you might want the manager to be completely separate... just an object in memory with references and functions designed to keep track of the on stage buttons for you. Later on, you'll get really tricky and have the button create the manager for itself if it doesn't already exist. ;-) -- Troy RPSystems, Ltd. http://www.rpsystems.net ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
