flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From OmPrakash Muppirala <bigosma...@gmail.com>
Subject Re: [FlexJS] Metadata based bead references
Date Sat, 09 Nov 2013 22:33:07 GMT
On Nov 8, 2013 5:22 PM, "Alex Harui" <aharui@adobe.com> wrote:
> On 11/8/13 4:09 PM, "OmPrakash Muppirala" <bigosmallm@gmail.com> 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
> >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
> >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.

To be clear, the approach I mentioned above, does work with CSS.  You only
need to specify the metadata for the class for the compiler to warn if a
required Bead reference is not available in the CSS.

> >
> >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?

Because CSS is supposed to be only for visual styling of components.  We
are doing much more than styling here.  Why not specify the dependencies in
an MXML file as a simple object?

Also, CSS lets things fail silently.  No exceptions or anything.  Whereas,
with your approach, when beads are not found, they cause RTEs.  Ideally,
they should throw compile errors when things are not missing.

CSS in general causes confusion for a developer because it allows things to
be strewn around in various different places.  Moreover, there is no IDE
support for code completion, etc.  By forcing developers to use more of CSS
as a way to pass dependencies, we are only making things harder for them.
And at the same time, we don't make use of the power of being a compiled

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message