Metadata

[Jacob Wright]

The Robot Legs group has been discussing how they want their framework to work in Flash Pro, and a large concern is that Flash Pro doesn't keep the metadata.

If we are wanting to work with Flash Pro, are we going to have to do everything without metadata? I know that's been a large part of how stealth and openflux have wired things together.

An alternative might be using namespaces for specific things. Example:

skinpart var upButton:Button;

instead of:

[Skinpart]

public var upButton:Button;

This won't help with [Bindable] but could work in other situations.

I think skinning will be different (could be different) for Flash Pro. Even the base component classes could be different. The main parts we want to keep between the two is the behaviors. I think if we code behaviors up to not need metadata, then we could have the rest of the system use it in Flex, and not use it in Flash Pro.

My opinions about the code-base is that we should make it #1 priority to have a usable system in Flash Builder. Usability in Flash Pro would be #2 priority. And somewhere way down the list of priorities is to try and keep the code-base the same, if it supports #1 and #2. But I don't want to keep the components for both the same if it means that it makes it difficult for people to use the components in Flex and Flash Pro. Not saying we will need to, but if we did need to maintain two sets of components for the two platforms, and it makes everyone else's lives easier, then I think we should. Or throw out Flash Pro. I don't want to have a clunky system for the sake of less work for us.

Jacob

[Tyler Wright]

I don't think we want to eliminate metadata, just have alternatives.

 

If we are wanting to work with Flash Pro, are we going to have to do everything without metadata? I know that's been a large part of how stealth and openflux have wired things together.

An alternative might be using namespaces for specific things. Example:

skinpart var upButton:Button;

instead of:

[Skinpart]

public var upButton:Button;

By keeping the [SkinPart] tag we'll benefit from the specific ASDoc features. Same goes for [Event] and possibly others.

This won't help with [Bindable] but could work in other situations.

[Bindable] is the big one, because it very conveniently code-gen's for you resulting in much nicer looking code. We'll have to eventually write out every getter/setter for bindable properties. The alternative isn't any nicer, and that is to go without binding altogether.

 

I think skinning will be different (could be different) for Flash Pro. Even the base component classes could be different. The main parts we want to keep between the two is the behaviors. I think if we code behaviors up to not need metadata, then we could have the rest of the system use it in Flex, and not use it in Flash Pro.

I agree we can treat some skinning methods between Flash Builder and Flash Pro as separate concerns, but I'd prefer having a single base for both environments. Apart from the code-gen metadata can be replaced with methods easily, in all cases. Again, it's the Binding that is the killer - such a convenient little tag with such an annoying alternative. I wish AS2's watch() was still around...

 

My opinions about the code-base is that we should make it #1 priority to have a usable system in Flash Builder. Usability in Flash Pro would be #2 priority. And somewhere way down the list of priorities is to try and keep the code-base the same, if it supports #1 and #2. But I don't want to keep the components for both the same if it means that it makes it difficult for people to use the components in Flex and Flash Pro. Not saying we will need to, but if we did need to maintain two sets of components for the two platforms, and it makes everyone else's lives easier, then I think we should. Or throw out Flash Pro. I don't want to have a clunky system for the sake of less work for us.

I would rather figure out some JSFL or SDK hacks in the Flash Pro environment then having two separate code-bases. I don't mind as much having separate component sets, but the core to the system should be the same. If we can have a unified component set that would be the ideal. I agree that right now we should focus on getting something working in a single environment (Flex) before we focus too much on all the different workflows.

Tyler