You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by OmPrakash Muppirala <bi...@gmail.com> on 2013/11/09 01:09:11 UTC
[FlexJS] Metadata based bead references
On Thu, Nov 7, 2013 at 5:22 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 11/7/13 4:54 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
> >On Thu, Nov 7, 2013 at 4:41 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> >>
> >>
> >> On 11/7/13 4:35 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
> >>
> >> >On Thu, Nov 7, 2013 at 2:18 PM, Alex Harui <ah...@adobe.com> wrote:
> >> >
> >> >> FWIW, I was thinking that this kind of check should be replaced by
> >>some
> >> >> capability in the tool chain to verify a configuration, maybe by
> >>marking
> >> >> some values as required. In production, you hopefully don't need
> >>these
> >> >> kinds of checks. I've also floated the idea of "debug-mode" beads
> >>which
> >> >> have more checks than production beads.
> >> >>
> >> >> Thoughts?
> >> >>
> >> >
> >> >Personally, I don't like the idea of setting the bead values in CSS.
> >>It
> >> >makes it hard to enforce these kind of things. Ideally, the absence
> >>of a
> >> >bead that the code is looking for should generate a compile error.
> >> >
> >> >Another way to inject beads would be to use metadata attributes.
> >> >Something
> >> >along the lines of spark skins' [SkinPart(required="true")] metadata
> >> >attribute. Would this make it easier to do the checks?
> >> That would help with the check, but are you also proposing naming the
> >> default value in the metadata?
> >>
> >>
> >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?
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?
Thanks,
Om
Re: [FlexJS] Metadata based bead references
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Nov 8, 2013 5:22 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>
> On 11/8/13 4:09 PM, "OmPrakash Muppirala" <bi...@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
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.
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
language.
Thanks,
Om
Re: [FlexJS] Metadata based bead references
Posted by Alex Harui <ah...@adobe.com>.
On 11/8/13 4:09 PM, "OmPrakash Muppirala" <bi...@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 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?