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
On Jul 16, 2013 1:05 AM, "Alex Harui" wrote:
>
> OK, pushed a bunch of changes to hopefully make it more easy/clear when
creating components.
>
> I added IBeadView, IBeadController and IBeadLayout interfaces to go along
with the already existing IBeadModel. The CSS makes it more clear now as
to w
OK, pushed a bunch of changes to hopefully make it more easy/clear when
creating components.
I added IBeadView, IBeadController and IBeadLayout interfaces to go along with
the already existing IBeadModel. The CSS makes it more clear now as to what
parts make up the component.
I renamed view b
17 matches
Mail list logo
