Ugh. Metadata, the "third" language. We'll have to add that to the list
of work items.
On 7/16/13 6:25 PM, "OmPrakash Muppirala" wrote:
>On Jul 16, 2013 5:14 PM, "Alex Harui" wrote:
>>
>>
>>
>> On 7/16/13 4:51 PM, "Carlos Rovira"
>>wrote:
>>
>> >That would be right if huge applications where
The target of "Applications" is heavily tied to lots of enhacements like
annotation/metadata, DI, AOP and so on...
All this kind of "commodities" are the kind of things that could make
FlexJS a better option over the miriad of JS frameworks out there. All this
things make easy to configure or chang
On Jul 16, 2013 5:14 PM, "Alex Harui" wrote:
>
>
>
> On 7/16/13 4:51 PM, "Carlos Rovira" wrote:
>
> >That would be right if huge applications where created in a consistent
and
> >homogeneous way during all "development life". If the app is tiny there's
> >more opportunities that experienced progr
On 7/16/13 4:51 PM, "Carlos Rovira" wrote:
>That would be right if huge applications where created in a consistent and
>homogeneous way during all "development life". If the app is tiny there's
>more opportunities that experienced programers make a good work and code
>in
>the overall.
>
>When t
On 7/16/13 4:29 PM, "OmPrakash Muppirala" wrote:
>> About folks rewriting code...well, I certainly does not see people
>> migrating old applications from Flex 4.x to FlexJS, Since there will be
>> huge diferences that will make the task utopic. I expect flex developers
>> start working in FlexJ
That would be right if huge applications where created in a consistent and
homogeneous way during all "development life". If the app is tiny there's
more opportunities that experienced programers make a good work and code in
the overall.
When the app, the team, the code grows over years, more diff
> About folks rewriting code...well, I certainly does not see people
> migrating old applications from Flex 4.x to FlexJS, Since there will be
> huge diferences that will make the task utopic. I expect flex developers
> start working in FlexJS right from the first day for new projects due to
> lots
Hi Alex,
Migration is still an important factor, but backward compatibility isn't
> being guaranteed. What that means to me is that I'm not promising that
> every API in current Flex will be there in FlexJS, and we are going to try
> to find the best API for the future, but if given a choice of
>>
>> The long answer: I was looking at how addToParent() is currently
>> implemented and found that I couldn't completely remember why I felt it
>> was a better strategy.
>
>I remember a conversation about trying to move away from the traditional
>display list approach so that we are not overly
On Jul 16, 2013 9:34 AM, "Alex Harui" wrote:
>
>
>
> >>
> >> Removed initModel and initSkin methods. The lifecycle is now much
> >simpler: instantiate, set properties and beads then add to the display
> >list. We're still using child.addToParent(parent), but I am going to
> >experiment next wit
On 7/16/13 1:57 PM, "flexcapaci...@gmail.com"
wrote:
>>A) wrapping addChild messed up a lot of low-level tools like display list
>> tree walkers used in Spy-like programs. I'm leaning against wrapping
>> addChild again.
>>
>
>What happened?
To walk the entire display list, you have to anticipa
Hi Carlos,
On 7/16/13 12:49 PM, "Carlos Rovira" wrote:
>Hi Alex,
>
>The short answer: to reduce migration pain. My internal customer showed
>> me a bunch of code with a lot of addElement() calls in it.
>>
>>
>I thought migration was not considered in FlexJS. IMHO, I think that
>should
>not be c
On Tue, Jul 16, 2013 at 11:33 AM, Alex Harui wrote:
>
>
> >>
> >> Removed initModel and initSkin methods. The lifecycle is now much
> >simpler: instantiate, set properties and beads then add to the display
> >list. We're still using child.addToParent(parent), but I am going to
> >experiment ne
Hi Alex,
The short answer: to reduce migration pain. My internal customer showed
> me a bunch of code with a lot of addElement() calls in it.
>
>
I thought migration was not considered in FlexJS. IMHO, I think that should
not be considered in the discussion of add to child vs add to parent.
>
>>
>> Removed initModel and initSkin methods. The lifecycle is now much
>simpler: instantiate, set properties and beads then add to the display
>list. We're still using child.addToParent(parent), but I am going to
>experiment next with changing over to parent.addElement(child).
>
>Any particul
t.addElement(child).
Any particular reason why? I was beginning to get a hang of the
child.addToParent() way.
>
> Thanks,
> -Alex
>
> From: Alex Harui mailto:aha...@adobe.com>>
> Date: Friday, July 12, 2013 11:19 AM
> To: "dev@flex.apache.org<mailto:dev@flex.ap
day, July 12, 2013 11:19 AM
To: "dev@flex.apache.org<mailto:dev@flex.apache.org>"
mailto:dev@flex.apache.org>>
Subject: [FlexJS] Doing some refactoring
FYI,
I'm doing some refactoring in the FlexJS code to try to simplify a few things
so life will be easier from here on
FYI,
I'm doing some refactoring in the FlexJS code to try to simplify a few things
so life will be easier from here on out. The main goal is to reduce the number
of calls when creating components in AS.
-Alex
18 matches
Mail list logo
