I believe MXML is supposed to treat more than one child in a child tag as
an array. And thus, the equivalent AS code for:
<js:initialView>
<local:MyInitialView id="view1" />
<local:MyOtherInitialView id="view2" />
</js:initialView>
is:
initialView = [ new MyInitialView, new MyOtherInitialView];
I understood the same, but I had thought it was supposed to be a bit
smarter than that and only assume an implicit <fx:Array> wrapper if it is
assigning to an Array typed property (maybe even 'Arraylike') property. I
will check the behavior using Flex 4 - I assume we want to keep whatever
'smarts' were implemented there, or at least as close as makes sense? I'll
also double check the compiler error for this same scenario in Flex 4,
which I did not do yet.
If you code that in AS, you will get an error (I hope), and I think the
compiler should report the same error for this MXML scenario, since
initialView is of type IApplicationView or something like that.
There might arguably be some justification for having an 'mxml version' of
an error, describing things more in mxml terms, particularly for new users
as they come on board and perhaps play with mxml examples first before
learning actionscript, but I will check both the actionscript error in
FlexJS and the mxml error in Flex 4 (assuming there is one) for this
scenario and report back here for consensus.
<js:initialView>
<js:SimpleCSSValuesImpl />
</js:initialView>
Is the equivalent of:
var initialView:IApplicationView = new SimpleCSSValuesImpl().
Exactly, and in the fix, I have this currently being described as:
In initializer for 'js:initialView', type
org.apache.flex.core.SimpleCSSValuesImpl
is not assignable to target type 'org.apache.flex.core.IApplicationView'.
I will check the FlexJS actionscript error for this also, but I definitely
pulled that one above as-is from Flex 4 for the same mxml problem (which is
also correctly treated as a compile time error)
On Fri, Mar 3, 2017 at 6:33 PM, Alex Harui <aha...@adobe.com> wrote:
> Hi Greg,
>
> Thanks for digging into this.
>
> Without having dug into it myself, I would like to suggest returning a
> type mismatch error of some sort. IIRC, the DuplicateChildTagProblem is
> for the following:
>
> <js:initialView>
> <local:MyInitialView id="view1" />
> </js:initialView>
> <js:initialView>
> <local:MyInitialView id="view2" />
>
> </js:initialView>
>
> The child tag (js:initialView) is really in there twice.
>
>
> I believe MXML is supposed to treat more than one child in a child tag as
> an array. And thus, the equivalent AS code for:
>
> <js:initialView>
> <local:MyInitialView id="view1" />
> <local:MyOtherInitialView id="view2" />
> </js:initialView>
>
> is:
>
> initialView = [ new MyInitialView, new MyOtherInitialView];
>
> If you code that in AS, you will get an error (I hope), and I think the
> compiler should report the same error for this MXML scenario, since
> initialView is of type IApplicationView or something like that.
>
> And same for the second scenario:
>
> <js:initialView>
> <js:SimpleCSSValuesImpl />
> </js:initialView>
>
> Is the equivalent of:
>
>
> var initialView:IApplicationView = new SimpleCSSValuesImpl().
>
> My 2 cents,
> -Alex
>
> On 3/2/17, 9:09 PM, "Greg Dove" <gregd...@apache.org> wrote:
>
> >I have been looking into FLEX-35273 [1].
> >
> >This is a compiler bug where it is possible to do things that don't make
> >sense, like:
> >
> ><js:initialView>
> > <local:MyInitialView id="view1" />
> > <local:MyInitialView id="view2" />
> ></js:initialView>
> >
> >or even this :
> >
> ><js:initialView>
> > <js:SimpleCSSValuesImpl />
> ></js:initialView>
> >
> >Neither of the above caused compile time errors.
> >
> >I have a fix for both the above scenarios.
> >
> >For the first one, I used MXMLDuplicateChildTagProblem which seems 'close
> >enough'
> >
> >"Child tag '${childTag}' bound to namespace '${childNamespace}' is
> >already specified for element '${element}'. It will be ignored.";
> >
> >This renders as :
> >Child tag 'MyInitialView' bound to namespace '*' is already specified for
> >element 'js:initialView'. It will be ignored.
> > <local:MyInitialView id="view2" />
> > ^
> >
> >in the first example above. The text does not feel entirely right, but
> >seems close enough. "It will be ignored" sounds more like a warning (as
> >opposed to an error/failure), which I think a) it should not be and b) it
> >is not.
> >
> >For the second one, I could not find any relevant 'Problem' class (I may
> >have missed one perhaps?) So I just made a new one. I don't really know
> >what the rules are here.
> >These Problems seem to include an error code so I am unclear what to do
> >if I add a new one. i.e. it is not clear what new error code I should
> >apply (or even if the error code is important for something).
> >For now I just added an arbitrary errorCode = 1999 on
> >MXMLBadChildTagPropertyAssignmentProblem.
> >
> >The new problem renders out to :
> >In initializer for 'js:initialView', type
> >org.apache.flex.core.SimpleCSSValuesImpl is not assignable to target type
> >'org.apache.flex.core.IApplicationView'.
> >
> >Alex, you may be able to advise here.... are there any rules I need to
> >follow for the CompilerProblem classes (in particular, when adding a new
> >class).
> >
> >Assuming all is well above, I will commit this fix tomorrow. I was also
> >trying to see if I could figure out how to get checkintests running, but
> >I so far I did not. However the regular build tests are all fine with the
> >changes I made for this.
> >
> >
> >1. https://issues.apache.org/jira/browse/FLEX-35273
>
>
