Passing parameters on initialization of custom flex component?

[Daedalus]

I'm a little confused about custom flex components and how to pass parameters to them when you delcare them.

If it was a pure actionscript project I could just add parameters to the constuctor function of my boot class, but I don't know how I would do it with a flex project that has a mxml file. i'm going to be compiling the project as a SWC file.

I want to do something like so>

var myComponent:CustomComp = new CustomComp(param1,param2);

I have coded my component all in AS3 but it must use a mxml class that boots my main class like this>

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:app="app.*" backgroundColor="#BBDDFF"
width="500" height="250" horizontalScrollPolicy="off" verticalScrollPolicy="off">
<app:Boot id="b"/>
</mx:Application>

Somehow I need to grab the passed parameters and send them to the Boot class.

[dr_zeus]

If you want to be able to create your component in MXML, the constructor must be able to run with zero parameters. You should expose these parameters as properties of your component.

<app:Boot id="b" param1="value1" param2="value2"/>

Flex is all about invalidation and validation, so you should account for changes to these values in commitProperties(), measure(), and/or updateDisplayList().

[Daedalus]

Ok thanks josh but i'm still not quite sure how to proceed.

The parameters are actually objects with name value pairs that specifiy configuration options for the component. I really want to handle these configuration options while the component is doing its startup business other wise it will asign the default configuration.

In terms of the mxml statement

<app:Boot id="b" param1="value1" param2="value2"/>

would this compile as>

var b:Boot = new Boot();
b.param1 = value1;
b.param2=value2;

If so then by the time I have set my params the deafult config has alreadey been applied which is not what I want.

However if the param1 and param2 propertys are set before the constructor of the Boot class is called then all is good as I can check the params to make sure they are not null. If they are null then the default config is used if not null then the config in my params are used.

[dr_zeus]

Why can't you set the default configuration first, and then change it later? It's standard practice for Flex components to be able to refresh themselves if a property changes at runtime. Replacing a default set of values shouldn't be any sort of problem if you're using the validation cycle correctly.

Here's a simple example that explains the process as it's meant to work:

var button:Button = new Button();
button.label = "Click Me!";
this.addChild(button)

Behind the scenes, setting the button's label stores it in a variable and invalidates the component. The text is not yet displayed because we need to assume that the UITextField instance that will display the text may not even exist yet. Standard practice is to create subcomponents in the createChildren() function which isn't called until the component is on the display list.

At some point in the future (not really important when this happens), the component begins validating and commitProperties() is called. This is a method available to all Flex components and custom components should override it for their own internal needs. Now, finally, the label text can be applied to the UITextField. The first validation pass doesn't happen until after createChildren() has been called and the component is on the display list. It is triggered again any time somthing changes and the component author calls invalidateProperties(), invalidateSize(), or invalidateDisplayList().

If you don't think this process will work for you, I suggest you go into more detail why you must access these configuration properties in the constructor so that we can make better suggestions to help you improve the component.

[Daedalus]

Ok thanks josh, I think I get it now.

I'll have to read up on the validation cycle concept, can't understand why I havent come accros it before. I've been overriding createChildren alot but i've never used commitProperties() or invalidateProperties() before.

It just seemed inefficient to me to assign a bunch of default values and then reassign custom values 50ms or so later.

i'll have a play around tommrow and try and get it sorted.

Thankyou for taking the time to post, its much appreciated.