You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Héctor A <ne...@gmail.com> on 2014/12/04 09:29:04 UTC
Re: Determining which MXML elements are containers
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 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.
>>>
>>
>>
>