You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Neverbirth <ne...@gmail.com> on 2014/10/14 21:34:39 UTC
Determining which MXML elements are containers
Hello everyone,
Tried to contact Alex with no luck, so will try posting here. As you may
know I'm working on bringing first class Flex support in FlashDevelop, and
I've recently found a case where I'm a bit puzzled on how it should be
properly implemented.
In particular, I want to know when a class can have another class as a
children. For example <s:Application> may have a <s:Button> as a child.
Right now this check is made:
(tmpClass.Implements.Contains("IContainer") // Flex
||
tmpClass.Implements.Contains("IVisualElementContainer")
||
tmpClass.Implements.Contains("IFocusManagerContainer")
|| tmpClass.Implements.Contains("IPopUpHost") //
FlexJS
|| tmpClass.Implements.Contains("IParent"))
But I find it a bit hacky, and I already found a case where it's failing.
I've thought of adding a check for [DefaultProperty], which will also
improve which classes are shown, but unless I have missed something it seems
not all container classes have a default property defined.
Do you happen to know which is the proper way of doing this? I'd like to
have proper support for Flex 4, FlexJS and Flex 3. I was thinking that maybe
it should check for both all those interfaces and a DefaultProperty
implementation, but I'm not too fond of that solution (unless there is no
other way, of course).
Thanks for your help.
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Determining-which-MXML-elements-are-containers-tp41370.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: Determining which MXML elements are containers
Posted by Alex Harui <ah...@adobe.com>.
On 10/14/14, 1:42 PM, "jude" <fl...@gmail.com> wrote:
>FYI There may not be an official way yet. In which case this would be a
>good discussion point. For example, there is not an official way to know
>if
>a class is a skin class.
Again, Gordon or Darrell (or better yet Ryan Frishberg if he’s still
lurking) might have a better answer, but I do not believe there is any
contract for a skin other than it must expose required the skin parts of
the host component. There is no interface to check, I think it has to be
an IVisualElement, but so does just about any UI thing in Spark.
Not sure how hard it is to get skin part metadata and public properties in
the various IDEs, but I think that’s what you’d have to do to see if a
skin is truly an allowed value, and searching for all matches could be
expensive if you are trying to offer valid values.
-Alex
Re: Determining which MXML elements are containers
Posted by jude <fl...@gmail.com>.
I would like to know the official way too.
FYI The Application is a special case. It is typed object so developers can
add their own properties and methods to it without the compiler
complaining. It should probably be treated as a special case.
In Flex 4 I've used IVisualElementContainer. For Flex 3 I think it's
IContainer but from Flex 4 on I think IVisualElementContainer should also
work. I don't know about FlexJS.
One case based purely on the Flash display list (not Flex) is to check if
the class is a subclass of DisplayObjectContainer?
BTW You may also need to check for IGraphicElementContainer.
In what cases did your check fail?
FYI There may not be an official way yet. In which case this would be a
good discussion point. For example, there is not an official way to know if
a class is a skin class. This needs to be figured out at some point as
well.
On Tue, Oct 14, 2014 at 2:34 PM, Neverbirth <ne...@gmail.com> wrote:
> Hello everyone,
>
> Tried to contact Alex with no luck, so will try posting here. As you may
> know I'm working on bringing first class Flex support in FlashDevelop, and
> I've recently found a case where I'm a bit puzzled on how it should be
> properly implemented.
>
> In particular, I want to know when a class can have another class as a
> children. For example <s:Application> may have a <s:Button> as a child.
>
> Right now this check is made:
>
> (tmpClass.Implements.Contains("IContainer") //
> Flex
> ||
> tmpClass.Implements.Contains("IVisualElementContainer")
> ||
> tmpClass.Implements.Contains("IFocusManagerContainer")
> || tmpClass.Implements.Contains("IPopUpHost") //
> FlexJS
> || tmpClass.Implements.Contains("IParent"))
>
> But I find it a bit hacky, and I already found a case where it's
> failing.
> I've thought of adding a check for [DefaultProperty], which will also
> improve which classes are shown, but unless I have missed something it
> seems
> not all container classes have a default property defined.
>
> Do you happen to know which is the proper way of doing this? I'd like to
> have proper support for Flex 4, FlexJS and Flex 3. I was thinking that
> maybe
> it should check for both all those interfaces and a DefaultProperty
> implementation, but I'm not too fond of that solution (unless there is no
> other way, of course).
>
> Thanks for your help.
>
>
>
> --
> View this message in context:
> http://apache-flex-development.2333347.n4.nabble.com/Determining-which-MXML-elements-are-containers-tp41370.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>
Re: Determining which MXML elements are containers
Posted by Héctor A <ne...@gmail.com>.
That's some great info Gordon. Once I finish some of my current tasks I'll
look again into MXML.
I'm working with the old compiler in mind, I'd love to see Falcon finished,
and being able to use it for code completion would be great if it proves to
be fast enough. Using the compiler services is how code completion works by
default for Haxe in FlashDevelop.
I'd like to help improving Falcon and any other of the Apache Flex
projects, but sadly don't have the time for it right now...
On Sat, Dec 13, 2014 at 10:30 PM, Gordon Smith <gs...@hotmail.com> wrote:
>
> I have a few points to belatedly make on this thread:
>
> 1. The 'specifications' folder of the 'flex-external' repository has a
> spec for MXML 2006 and 2009. It's incomplete, but it's the best one that
> exists. If you find that it doesn't answer your questions about which
> elements are allowed inside which elements, please let me know where
> specific information is missing or wrong and I'll try to improve the spec.
>
> 2. In the new Falcon compiler, MXMLNodeBase, the abstract base class for
> all nodes in the MXML syntax tree, has a method called processChildTag()
> which gets overridden in each subclass to process the allowed child tags
> (i.e., elements). For example, if you look at this method in
> MXMLDeclarationsNode (which represents <fx:Declarations>) you can see that
> MXMLComponentNode (representing <fx:Component>), MXMLModelNode
> (representing <fx:Model>), and MXMLInstanceNode (representing tags like
> <s:Button> and <fx:int>) are allowed, while all other tags are disallowed.
> Since Falcon hasn't been completed, this may or may not match the logic in
> the old compiler and in the spec, but the information still may be of some
> use to you. In any case, if you're using Falcon, your code hinting will
> match what the compiler allows. Are you working to incorporate Falcon into
> an IDE, or the old compiler?
>
> 3. In my opinion, code-hinting logic belongs in Falcon, and it would be
> great it you would add it there rather than in one particular IDE. Falcon
> was always intended to be a code-intelligence engine to support IDE
> editing, and not just a compiler.
>
> - Gordon
>
>
Re: Determining which MXML elements are containers
Posted by Darrell Loverin <da...@gmail.com>.
Setting the itemRenderer goes thru the same error checking as any other
assignment statement so that why there is no special case error checking
code for IFactory. There is special handling for IFactory. For the inline
MXML assignment to itemRenderer the compiler generates a "new
ClassFactory()" and assigns that to itemRenderer. It is easier to
understand if you look at the generated AS code by adding "-keep" to the
command.
Below are some methods that might help you understand what is happening:
*See references to StandardDefs.isIFactory().
*See the TypeCompatibility.check() method in the MXML compiler.
Hope that helps,
-Darrell
-Darrell
On Fri, Dec 5, 2014 at 9:29 AM, Darrell Loverin <da...@gmail.com>
wrote:
> I'll have some time this weekend to look at this a bit.
>
>
> -Darrell
>
> On Thu, Dec 4, 2014 at 3:29 AM, Héctor A <ne...@gmail.com> wrote:
>
>> Hello again Darrell, and sorry for bothering one more time,
>>
>> I've been browsing the MXMLC source looking for IFactory info, but I
>> couldn't find what I need. How do I determine the type of class/interface
>> expected by an IFactory? is it posible or must I add it case by case? I've
>> seen that when the type value is defined as a child tag it allows for other
>> IFactory types as expected:
>>
>> <s:List>
>> <s:itemRenderer>
>> <custom:CustomFactory/>
>> </s:itemRenderer>
>> </s:List>
>>
>> However, when defining it as an attribute it allows for clases
>> implementing IItemRenderer as well:
>>
>> <s:List itemRenderer="CustomRenderer"/>
>>
>> Is it possible to get the correct type dynamically? I haven't find
>> anything on either the SDK or compiler source, so it may not be possible
>> and implemented in the IDE itself.
>>
>> Best regards,
>>
>>
>> On Tue, Nov 25, 2014 at 3:47 AM, Darrell Loverin <
>> darrell.loverin@gmail.com> wrote:
>>
>>> >>Right now none because the property is private, and if it wasn't,
>>> just subclasses.
>>> That sounds right to me.
>>>
>>>
>>> -Darrell
>>>
>>> On Sun, Nov 23, 2014 at 8:34 PM, Héctor A <ne...@gmail.com> wrote:
>>>
>>>>
>>>> >>property of type NavigationStack, marked with [ExcludeClass], what
>>>>> does that mean?
>>>>>
>>>>> [ExcludeClass] prevents FlashBuilder from hinting the class and
>>>>> excludes it from ASDoc.
>>>>>
>>>>> I know, I guess I made myself not too clear. I meant with regards to
>>>> children nodes auto-completion, subclasses may not be excluded, but again,
>>>> the default property is marked private, and at least in fd case the
>>>> property info is not always available. So, which class types could appear
>>>> in that case? None? NavigationStack subclasses? Right now none because
>>>> the property is private, and if it wasn't, just subclasses.
>>>>
>>>
>>>
>>
>
RE: Determining which MXML elements are containers
Posted by Gordon Smith <gs...@hotmail.com>.
I have a few points to belatedly make on this thread:
1. The 'specifications' folder of the 'flex-external' repository has a spec for MXML 2006 and 2009. It's incomplete, but it's the best one that exists. If you find that it doesn't answer your questions about which elements are allowed inside which elements, please let me know where specific information is missing or wrong and I'll try to improve the spec.
2. In the new Falcon compiler, MXMLNodeBase, the abstract base class for all nodes in the MXML syntax tree, has a method called processChildTag() which gets overridden in each subclass to process the allowed child tags (i.e., elements). For example, if you look at this method in MXMLDeclarationsNode (which represents <fx:Declarations>) you can see that MXMLComponentNode (representing <fx:Component>), MXMLModelNode (representing <fx:Model>), and MXMLInstanceNode (representing tags like <s:Button> and <fx:int>) are allowed, while all other tags are disallowed. Since Falcon hasn't been completed, this may or may not match the logic in the old compiler and in the spec, but the information still may be of some use to you. In any case, if you're using Falcon, your code hinting will match what the compiler allows. Are you working to incorporate Falcon into an IDE, or the old compiler?
3. In my opinion, code-hinting logic belongs in Falcon, and it would be great it you would add it there rather than in one particular IDE. Falcon was always intended to be a code-intelligence engine to support IDE editing, and not just a compiler.
- Gordon
Re: Determining which MXML elements are containers
Posted by Darrell Loverin <da...@gmail.com>.
I'll have some time this weekend to look at this a bit.
-Darrell
On Thu, Dec 4, 2014 at 3:29 AM, Héctor A <ne...@gmail.com> wrote:
> Hello again Darrell, and sorry for bothering one more time,
>
> I've been browsing the MXMLC source looking for IFactory info, but I
> couldn't find what I need. How do I determine the type of class/interface
> expected by an IFactory? is it posible or must I add it case by case? I've
> seen that when the type value is defined as a child tag it allows for other
> IFactory types as expected:
>
> <s:List>
> <s:itemRenderer>
> <custom:CustomFactory/>
> </s:itemRenderer>
> </s:List>
>
> However, when defining it as an attribute it allows for clases
> implementing IItemRenderer as well:
>
> <s:List itemRenderer="CustomRenderer"/>
>
> Is it possible to get the correct type dynamically? I haven't find
> anything on either the SDK or compiler source, so it may not be possible
> and implemented in the IDE itself.
>
> Best regards,
>
>
> On Tue, Nov 25, 2014 at 3:47 AM, Darrell Loverin <
> darrell.loverin@gmail.com> wrote:
>
>> >>Right now none because the property is private, and if it wasn't, just
>> subclasses.
>> That sounds right to me.
>>
>>
>> -Darrell
>>
>> On Sun, Nov 23, 2014 at 8:34 PM, Héctor A <ne...@gmail.com> wrote:
>>
>>>
>>> >>property of type NavigationStack, marked with [ExcludeClass], what
>>>> does that mean?
>>>>
>>>> [ExcludeClass] prevents FlashBuilder from hinting the class and
>>>> excludes it from ASDoc.
>>>>
>>>> I know, I guess I made myself not too clear. I meant with regards to
>>> children nodes auto-completion, subclasses may not be excluded, but again,
>>> the default property is marked private, and at least in fd case the
>>> property info is not always available. So, which class types could appear
>>> in that case? None? NavigationStack subclasses? Right now none because
>>> the property is private, and if it wasn't, just subclasses.
>>>
>>
>>
>
Re: Determining which MXML elements are containers
Posted by Héctor A <ne...@gmail.com>.
Hello again Darrell, and sorry for bothering one more time,
I've been browsing the MXMLC source looking for IFactory info, but I
couldn't find what I need. How do I determine the type of class/interface
expected by an IFactory? is it posible or must I add it case by case? I've
seen that when the type value is defined as a child tag it allows for other
IFactory types as expected:
<s:List>
<s:itemRenderer>
<custom:CustomFactory/>
</s:itemRenderer>
</s:List>
However, when defining it as an attribute it allows for clases
implementing IItemRenderer as well:
<s:List itemRenderer="CustomRenderer"/>
Is it possible to get the correct type dynamically? I haven't find
anything on either the SDK or compiler source, so it may not be possible
and implemented in the IDE itself.
Best regards,
On Tue, Nov 25, 2014 at 3:47 AM, Darrell Loverin <da...@gmail.com>
wrote:
> >>Right now none because the property is private, and if it wasn't, just
> subclasses.
> That sounds right to me.
>
>
> -Darrell
>
> On Sun, Nov 23, 2014 at 8:34 PM, Héctor A <ne...@gmail.com> wrote:
>
>>
>> >>property of type NavigationStack, marked with [ExcludeClass], what does
>>> that mean?
>>>
>>> [ExcludeClass] prevents FlashBuilder from hinting the class and excludes
>>> it from ASDoc.
>>>
>>> I know, I guess I made myself not too clear. I meant with regards to
>> children nodes auto-completion, subclasses may not be excluded, but again,
>> the default property is marked private, and at least in fd case the
>> property info is not always available. So, which class types could appear
>> in that case? None? NavigationStack subclasses? Right now none because
>> the property is private, and if it wasn't, just subclasses.
>>
>
>
Re: Determining which MXML elements are containers
Posted by Darrell Loverin <da...@gmail.com>.
>>Right now none because the property is private, and if it wasn't, just
subclasses.
That sounds right to me.
-Darrell
On Sun, Nov 23, 2014 at 8:34 PM, Héctor A <ne...@gmail.com> wrote:
>
> >>property of type NavigationStack, marked with [ExcludeClass], what does
>> that mean?
>>
>> [ExcludeClass] prevents FlashBuilder from hinting the class and excludes
>> it from ASDoc.
>>
>> I know, I guess I made myself not too clear. I meant with regards to
> children nodes auto-completion, subclasses may not be excluded, but again,
> the default property is marked private, and at least in fd case the
> property info is not always available. So, which class types could appear
> in that case? None? NavigationStack subclasses? Right now none because
> the property is private, and if it wasn't, just subclasses.
>
Re: Determining which MXML elements are containers
Posted by Héctor A <ne...@gmail.com>.
> >>property of type NavigationStack, marked with [ExcludeClass], what does
> that mean?
>
> [ExcludeClass] prevents FlashBuilder from hinting the class and excludes
> it from ASDoc.
>
> I know, I guess I made myself not too clear. I meant with regards to
children nodes auto-completion, subclasses may not be excluded, but again,
the default property is marked private, and at least in fd case the
property info is not always available. So, which class types could appear
in that case? None? NavigationStack subclasses? Right now none because the
property is private, and if it wasn't, just subclasses.
Re: Determining which MXML elements are containers
Posted by Darrell Loverin <da...@gmail.com>.
>>property of type NavigationStack, marked with [ExcludeClass], what does
that mean?
[ExcludeClass] prevents FlashBuilder from hinting the class and excludes it
from ASDoc.
-Darrell
On Sun, Nov 23, 2014 at 6:49 PM, Darrell Loverin <da...@gmail.com>
wrote:
> I not sure how complete the MXML support in the falcon compiler so I
> checked the old mxmlc compiler. The old mxmlc validates with specialized
> if/else statements based on parent and child types for elements that do not
> provide [DefaultProperty]. For example, here is a code snippet from
> ComponentBuilder.ComponentChildNodeHandler.nestedDeclaration():
>
> // Halo navigators (Accordion, TagNavigator, and
>
> // ViewStack) only support container based children.
>
> if (checkHaloNavigatorRequirements &&
>
> standardDefs.isHaloNavigator(parentType) &&
>
> !standardDefs.isNavigatorContent(childType) &&
>
> !(child instanceof ReparentNode))
>
> {
>
> log(child, new
> HaloNavigatorsRequireHaloContainerChildren());
>
> }
>
> See the whole method for all the checks.
> Also see the checks in DocumentChildNodeHandler.nestedDeclarations() as
> well.
>
> Hope this helps,
>
>
> -Darrell
>
> On Fri, Nov 21, 2014 at 11:51 AM, Héctor A <ne...@gmail.com> wrote:
>
>> Thank you very much for the reply Darrell, your help would be highly
>> appreciated. I have some doubts, and I guess some more will be popping up,
>> but if I can avoid having to find out about them the less time it will take
>> to have a better IDE.
>>
>> I've seen ViewNavigatorApplication and ViewNavigator has
>> [DefaultProperty("navigationStack")] , which is a private property of type
>> NavigationStack, marked with [ExcludeClass], what does that mean? right now
>> it renders DefaultProperty to be null, which I suppose is the right thing
>> to do.
>>
>> How are the possible fx: types for a node determined? is there a set of
>> rules determined? after a root node, a fx:Declaration element, a component
>> declaration, an ItemRenderer... is it hacked around? I guess so, but I'll
>> have to think about how to handle those special cases properly.
>>
>> I haven't looked into Flex 3 in depth yet.
>>
>>
>> On Fri, Nov 21, 2014 at 2:31 PM, Darrell Loverin <
>> darrell.loverin@gmail.com> wrote:
>>
>>> Sorry I missed this thread. Using [DefaultProperty] and
>>> [ArrayElementType] sounds right for Spark components but I don't see
>>> [DefaultProperty] declared in mx containers and I don't remember how mx
>>> containers were validated. I'll investigate to see how it works this
>>> weekend.
>>>
>>>
>>> -Darrell
>>>
>>> On Thu, Nov 20, 2014 at 4:38 PM, Héctor A <ne...@gmail.com> wrote:
>>>
>>>> Cc-ing Gordon and Darrell here, in case they missed this thread.
>>>>>
>>>>
>>>> Thanks, that would be the better source of information and the best way
>>>> to make sure I implement everything as it should.
>>>>
>>>> I didn't mention it, but of course I added support for ArrayElementType
>>>> and InstanceType metas as well, although I didn't test any case where it is
>>>> used inside a SWC yet, so it may fail in that case.
>>>>
>>>> I'll need to come up with every example and test case possible,
>>>>
>>>
>>>
>>
>
Re: Determining which MXML elements are containers
Posted by Héctor A <ne...@gmail.com>.
Thanks for the tip, it will be rather helpful when the time comes, right
now I've hit some sort of roadblock, I've extended support for
ArrayElementType and DefaultProperty, and I've seen the more classes FD has
to check, the more time it takes to check type constraints. There isn't any
sort of cache for it, and I have to check the complete inheritance chain
for every type every time, so I'll have to come up with something.
On Mon, Nov 24, 2014 at 12:49 AM, Darrell Loverin <darrell.loverin@gmail.com
> wrote:
> I not sure how complete the MXML support in the falcon compiler so I
> checked the old mxmlc compiler. The old mxmlc validates with specialized
> if/else statements based on parent and child types for elements that do not
> provide [DefaultProperty]. For example, here is a code snippet from
> ComponentBuilder.ComponentChildNodeHandler.nestedDeclaration():
>
> // Halo navigators (Accordion, TagNavigator, and
>
> // ViewStack) only support container based children.
>
> if (checkHaloNavigatorRequirements &&
>
> standardDefs.isHaloNavigator(parentType) &&
>
> !standardDefs.isNavigatorContent(childType) &&
>
> !(child instanceof ReparentNode))
>
> {
>
> log(child, new
> HaloNavigatorsRequireHaloContainerChildren());
>
> }
>
> See the whole method for all the checks.
> Also see the checks in DocumentChildNodeHandler.nestedDeclarations() as
> well.
>
> Hope this helps,
>
>
> -Darrell
>
> On Fri, Nov 21, 2014 at 11:51 AM, Héctor A <ne...@gmail.com> wrote:
>
>> Thank you very much for the reply Darrell, your help would be highly
>> appreciated. I have some doubts, and I guess some more will be popping up,
>> but if I can avoid having to find out about them the less time it will take
>> to have a better IDE.
>>
>> I've seen ViewNavigatorApplication and ViewNavigator has
>> [DefaultProperty("navigationStack")] , which is a private property of type
>> NavigationStack, marked with [ExcludeClass], what does that mean? right now
>> it renders DefaultProperty to be null, which I suppose is the right thing
>> to do.
>>
>> How are the possible fx: types for a node determined? is there a set of
>> rules determined? after a root node, a fx:Declaration element, a component
>> declaration, an ItemRenderer... is it hacked around? I guess so, but I'll
>> have to think about how to handle those special cases properly.
>>
>> I haven't looked into Flex 3 in depth yet.
>>
>>
>> On Fri, Nov 21, 2014 at 2:31 PM, Darrell Loverin <
>> darrell.loverin@gmail.com> wrote:
>>
>>> Sorry I missed this thread. Using [DefaultProperty] and
>>> [ArrayElementType] sounds right for Spark components but I don't see
>>> [DefaultProperty] declared in mx containers and I don't remember how mx
>>> containers were validated. I'll investigate to see how it works this
>>> weekend.
>>>
>>>
>>> -Darrell
>>>
>>> On Thu, Nov 20, 2014 at 4:38 PM, Héctor A <ne...@gmail.com> wrote:
>>>
>>>> Cc-ing Gordon and Darrell here, in case they missed this thread.
>>>>>
>>>>
>>>> Thanks, that would be the better source of information and the best way
>>>> to make sure I implement everything as it should.
>>>>
>>>> I didn't mention it, but of course I added support for ArrayElementType
>>>> and InstanceType metas as well, although I didn't test any case where it is
>>>> used inside a SWC yet, so it may fail in that case.
>>>>
>>>> I'll need to come up with every example and test case possible,
>>>>
>>>
>>>
>>
>
Re: Determining which MXML elements are containers
Posted by Darrell Loverin <da...@gmail.com>.
I not sure how complete the MXML support in the falcon compiler so I
checked the old mxmlc compiler. The old mxmlc validates with specialized
if/else statements based on parent and child types for elements that do not
provide [DefaultProperty]. For example, here is a code snippet from
ComponentBuilder.ComponentChildNodeHandler.nestedDeclaration():
// Halo navigators (Accordion, TagNavigator, and
// ViewStack) only support container based children.
if (checkHaloNavigatorRequirements &&
standardDefs.isHaloNavigator(parentType) &&
!standardDefs.isNavigatorContent(childType) &&
!(child instanceof ReparentNode))
{
log(child, new
HaloNavigatorsRequireHaloContainerChildren());
}
See the whole method for all the checks.
Also see the checks in DocumentChildNodeHandler.nestedDeclarations() as
well.
Hope this helps,
-Darrell
On Fri, Nov 21, 2014 at 11:51 AM, Héctor A <ne...@gmail.com> wrote:
> Thank you very much for the reply Darrell, your help would be highly
> appreciated. I have some doubts, and I guess some more will be popping up,
> but if I can avoid having to find out about them the less time it will take
> to have a better IDE.
>
> I've seen ViewNavigatorApplication and ViewNavigator has
> [DefaultProperty("navigationStack")] , which is a private property of type
> NavigationStack, marked with [ExcludeClass], what does that mean? right now
> it renders DefaultProperty to be null, which I suppose is the right thing
> to do.
>
> How are the possible fx: types for a node determined? is there a set of
> rules determined? after a root node, a fx:Declaration element, a component
> declaration, an ItemRenderer... is it hacked around? I guess so, but I'll
> have to think about how to handle those special cases properly.
>
> I haven't looked into Flex 3 in depth yet.
>
>
> On Fri, Nov 21, 2014 at 2:31 PM, Darrell Loverin <
> darrell.loverin@gmail.com> wrote:
>
>> Sorry I missed this thread. Using [DefaultProperty] and
>> [ArrayElementType] sounds right for Spark components but I don't see
>> [DefaultProperty] declared in mx containers and I don't remember how mx
>> containers were validated. I'll investigate to see how it works this
>> weekend.
>>
>>
>> -Darrell
>>
>> On Thu, Nov 20, 2014 at 4:38 PM, Héctor A <ne...@gmail.com> wrote:
>>
>>> Cc-ing Gordon and Darrell here, in case they missed this thread.
>>>>
>>>
>>> Thanks, that would be the better source of information and the best way
>>> to make sure I implement everything as it should.
>>>
>>> I didn't mention it, but of course I added support for ArrayElementType
>>> and InstanceType metas as well, although I didn't test any case where it is
>>> used inside a SWC yet, so it may fail in that case.
>>>
>>> I'll need to come up with every example and test case possible,
>>>
>>
>>
>
Re: Determining which MXML elements are containers
Posted by Héctor A <ne...@gmail.com>.
Thank you very much for the reply Darrell, your help would be highly
appreciated. I have some doubts, and I guess some more will be popping up,
but if I can avoid having to find out about them the less time it will take
to have a better IDE.
I've seen ViewNavigatorApplication and ViewNavigator has
[DefaultProperty("navigationStack")] , which is a private property of type
NavigationStack, marked with [ExcludeClass], what does that mean? right now
it renders DefaultProperty to be null, which I suppose is the right thing
to do.
How are the possible fx: types for a node determined? is there a set of
rules determined? after a root node, a fx:Declaration element, a component
declaration, an ItemRenderer... is it hacked around? I guess so, but I'll
have to think about how to handle those special cases properly.
I haven't looked into Flex 3 in depth yet.
On Fri, Nov 21, 2014 at 2:31 PM, Darrell Loverin <da...@gmail.com>
wrote:
> Sorry I missed this thread. Using [DefaultProperty] and [ArrayElementType]
> sounds right for Spark components but I don't see [DefaultProperty]
> declared in mx containers and I don't remember how mx containers were
> validated. I'll investigate to see how it works this weekend.
>
>
> -Darrell
>
> On Thu, Nov 20, 2014 at 4:38 PM, Héctor A <ne...@gmail.com> wrote:
>
>> Cc-ing Gordon and Darrell here, in case they missed this thread.
>>>
>>
>> Thanks, that would be the better source of information and the best way
>> to make sure I implement everything as it should.
>>
>> I didn't mention it, but of course I added support for ArrayElementType
>> and InstanceType metas as well, although I didn't test any case where it is
>> used inside a SWC yet, so it may fail in that case.
>>
>> I'll need to come up with every example and test case possible,
>>
>
>
Re: Determining which MXML elements are containers
Posted by Darrell Loverin <da...@gmail.com>.
Sorry I missed this thread. Using [DefaultProperty] and [ArrayElementType]
sounds right for Spark components but I don't see [DefaultProperty]
declared in mx containers and I don't remember how mx containers were
validated. I'll investigate to see how it works this weekend.
-Darrell
On Thu, Nov 20, 2014 at 4:38 PM, Héctor A <ne...@gmail.com> wrote:
> Cc-ing Gordon and Darrell here, in case they missed this thread.
>>
>
> Thanks, that would be the better source of information and the best way to
> make sure I implement everything as it should.
>
> I didn't mention it, but of course I added support for ArrayElementType
> and InstanceType metas as well, although I didn't test any case where it is
> used inside a SWC yet, so it may fail in that case.
>
> I'll need to come up with every example and test case possible,
>
Re: Determining which MXML elements are containers
Posted by Héctor A <ne...@gmail.com>.
>
> Cc-ing Gordon and Darrell here, in case they missed this thread.
>
Thanks, that would be the better source of information and the best way to
make sure I implement everything as it should.
I didn't mention it, but of course I added support for ArrayElementType and
InstanceType metas as well, although I didn't test any case where it is
used inside a SWC yet, so it may fail in that case.
I'll need to come up with every example and test case possible,
Re: Determining which MXML elements are containers
Posted by OmPrakash Muppirala <bi...@gmail.com>.
Thanks for the update!
Cc-ing Gordon and Darrell here, in case they missed this thread.
Thanks,
Om
On Thu, Nov 20, 2014 at 1:10 PM, Neverbirth <ne...@gmail.com> wrote:
> I added support for DefaultProperty today, but there are many cases to
> check
> to make sure everything is supported as expected.
>
> Well, at any rate this is a nice improvement, many cases where the
> completion list wasn't showing any type are now working, but there are
> cases
> still showing more than they should and a few missing cases.
>
> Gordon and/or Darrell didn't drop by, which is a bit of a shame as it would
> ease all of the process.
>
>
>
> --
> View this message in context:
> http://apache-flex-development.2333347.n4.nabble.com/Determining-which-MXML-elements-are-containers-tp41370p42583.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>
Re: Determining which MXML elements are containers
Posted by Neverbirth <ne...@gmail.com>.
I added support for DefaultProperty today, but there are many cases to check
to make sure everything is supported as expected.
Well, at any rate this is a nice improvement, many cases where the
completion list wasn't showing any type are now working, but there are cases
still showing more than they should and a few missing cases.
Gordon and/or Darrell didn't drop by, which is a bit of a shame as it would
ease all of the process.
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Determining-which-MXML-elements-are-containers-tp41370p42583.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: Determining which MXML elements are containers
Posted by Alex Harui <ah...@adobe.com>.
On 10/14/14, 3:04 PM, "Neverbirth" <ne...@gmail.com> wrote:
>And how could I contact Gordon and/or Darrell? Or could someone forward
>them
>to this thread?
They both subscribe to the list, but don’t answer every day.
-Alex
Re: Determining which MXML elements are containers
Posted by OmPrakash Muppirala <bi...@gmail.com>.
Neverbirth, please make sure you are subscribed to the dev@flex.apache.org
mailing list. Every email of yours is getting into the moderation queue.
I am guessing that is because you are not subscribed to this list.
Send an email to: dev-subscribe@flex.apache.org to subscribe.
Thanks,
Om
On Tue, Oct 14, 2014 at 3:04 PM, Neverbirth <ne...@gmail.com> wrote:
> And how could I contact Gordon and/or Darrell? Or could someone forward
> them
> to this thread?
>
> Thanks in advance, and sorry for the inconvenience.
>
>
>
> --
> View this message in context:
> http://apache-flex-development.2333347.n4.nabble.com/Determining-which-MXML-elements-are-containers-tp41370p41385.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>
Re: Determining which MXML elements are containers
Posted by Neverbirth <ne...@gmail.com>.
And how could I contact Gordon and/or Darrell? Or could someone forward them
to this thread?
Thanks in advance, and sorry for the inconvenience.
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Determining-which-MXML-elements-are-containers-tp41370p41385.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: Determining which MXML elements are containers
Posted by Alex Harui <ah...@adobe.com>.
This is why Gordon and Darrell are probably better suited to answer these
questions. mx:Container is probably special-cased as I don’t see metadata
for it either. IIRC, the compiler generates these things called
UIComponentDescriptors for mx containers. For Spark and FlexJS, we are
using [DefaultProperty]. Spark also uses [ArrayElementType] and we should
add the right ArrayElementType values to the FlexJS code.
On 10/14/14, 2:44 PM, "Neverbirth" <ne...@gmail.com> wrote:
>Thanks for your replies.
>
>My doubt comes from containers and the like, for example, how does an IDE
>know the direct child of <mx:Container> can be objects inheriting from,
>eg,
>a GraphicElement? I'm a bit familiar with DefaultProperty (and
>ArrayElementType), but I didn't see it in that case, did I overlook it? or
>is it a special case? And if it's a special case, which are the proper
>interfaces and/or classes to check depending of each framework?
>
>The failing cases I've seen come from custom implementations that define a
>DefaultProperty, but I'd like to cover every case possible correctly.
>
>
>
>--
>View this message in context:
>http://apache-flex-development.2333347.n4.nabble.com/Determining-which-MXM
>L-elements-are-containers-tp41370p41381.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: Determining which MXML elements are containers
Posted by Neverbirth <ne...@gmail.com>.
Thanks for your replies.
My doubt comes from containers and the like, for example, how does an IDE
know the direct child of <mx:Container> can be objects inheriting from, eg,
a GraphicElement? I'm a bit familiar with DefaultProperty (and
ArrayElementType), but I didn't see it in that case, did I overlook it? or
is it a special case? And if it's a special case, which are the proper
interfaces and/or classes to check depending of each framework?
The failing cases I've seen come from custom implementations that define a
DefaultProperty, but I'd like to cover every case possible correctly.
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Determining-which-MXML-elements-are-containers-tp41370p41381.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: Determining which MXML elements are containers
Posted by Alex Harui <ah...@adobe.com>.
Assuming you tried to contact me, I did not see anything from you, but in
general asking on this list is best.
On 10/14/14, 12:34 PM, "Neverbirth" <ne...@gmail.com> wrote:
>
> In particular, I want to know when a class can have another class as a
>children. For example <s:Application> may have a <s:Button> as a child.
I’m not sure I understand the question. Are you trying to determine when
the value of any property can be a non-primitive, or when the default
property value can be a non-primitive, or when the default property value
can be an array of non-primitives? Or are you only concerned about
display object children?
Gordon or Darrell might be able to explain it better, but here’s my
version:
In MXML, you have a tag and then in some cases you want to specify the
value of certain properties as object instances via sub-tags. For example
for this class:
public class MyClass
{
public var someproperty:Object;
public var someotherproperty:Object;
}
You can declare it in MXML and assign values to properties like this:
<MyClass>
<someproperty>
<SomeSubTag />
</someproperty>
<someotherproperty>
<SomeOtherSubTag />
</someotherproperty>
</MyClass>
The [DefaultProperty] metadata allows you to specify the value of a
property without the property name tags, so by adding
[DefaultProperty(“someotherproperty”)] to MyClass.as, you can then declare
it like this:
<MyClass>
<someproperty>
<SomeSubTag />
</someproperty>
<SomeOtherSubTag />
</MyClass>
So, fundamentally, the allowed sub-tags of a tag that aren’t wrapped in a
property name tag is completely dependent on whether the default property
allows for non-primitives. I don’t think we ever do this, but the default
property of some class could be a String or Number.
Most of our default properties, especially for UI “containers” is an
Array. We have not filled out [ArrayElementType] metadata for FlexJS yet,
but for the Flex SDK, there should be [ArrayElementType] metadata that
dictate what is allowed as the value of a default property of type Array.
And if it is missing, feel free to add it.
I believe there are non-display object tags in Flex like RemoteObject that
take Operations as children, so this protocol isn’t just limited to UI
declarations.
HTH,
-Alex