>>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 <darrell.love...@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 <neverbi...@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.love...@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 <neverbi...@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,
>>>>
>>>
>>>
>>
>

Reply via email to