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.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,
>>>>
>>>
>>>
>>
>
