On 11/8/13 4:09 PM, "OmPrakash Muppirala" <[email protected]> wrote:
>>>Yes, setting the default values in metadata would be great. It is more
>>>in
>> >tune with how Flex works in today.
>> Maybe I'm not understanding. SkinPart doesn't set a default value.
>>Lots
>> of things are set in defaults.css. What metadata are you thinking of?
>>
>>
>
>You are right. I was not very clear. One way to go about it is, in the
>component:
>
>ControlBar.as
>
>[BeadReference("IBeadLayout", type="org.apache.flex.core.IBeadLayout",
>required="true")]
>public class ControlBar extends Container implements IContainer, IChrome
>{
> override public function addedToParent():void
> {
> super.addedToParent();
>
> if( getBeadByType(IBeadLayout) == null ) {
> var layout:IBeadLayout = new
>(ValuesManager.valuesImpl.getValue(this, "IBeadLayout")) as IBeadLayout;
> addBead(layout);
> }
> }
>}
>
>In the above approach, the component developer could specify all the beads
>utilized in the component by listing them out at the top of the class.
>Also, we could have stricter type checking by specifying the Interface the
>bead should implement.
>We could optionally mention if the bead is required or not. If it is not
>required, then the component developer should be using a default one. If
>an entry is 'required' and not available in the CSS file, the compiler
>would throw an error.
>
>Your thoughts on this approach?
How does the developer change the bead for several instances of a class at
once. That's why I chose CSS. It has several ways of assigning things.
I think the tools or optional beads can confirm configuration issues
without burdening the 80% of folks who got it right and don't need any
checking in production.
>
>I am thinking through another approach where we don't specify anything in
>the .css file, but use a dependency injection paradigm more on the lines
>of
>Parsley, Robotlegs, etc. Do you think that is worth discussing?
Worth discussing. I prefer having each object pick up its dependencies
when it needs it, not at particular points in time. IMO, a centralized DI
subsystem doesn't allow as much flexibility around timing. Lots of
things will be picking up styles, so why not pick up dependencies the same
way?
