Ah ok. I wasn't aware that the custom UI components was a separate piece.
Thanks,
-Alex
On 7/9/14 11:20 PM, "Harbs" wrote:
>Angular does not provide the "lego". Rather, it describes how the pieces
>are supposed to connect and how the pieces should be constructed.
>
>Angular is all about connect
Angular does not provide the "lego". Rather, it describes how the pieces are
supposed to connect and how the pieces should be constructed.
Angular is all about connecting the html markup with javascript.
Angular introduces custom html attributes (the default ones are prefixed ng but
custom ones
On 7/9/14 3:32 PM, "Harbs" wrote:
>It seems to me there¹s a question of perception as to what ³Flex² is.
>
>Historically, Flex has been an application framework centered around
>components. The equivalent in the JS world would probably be something
>like Sencha¹s UI frameworks. (i.e. ext js) or J
It seems to me there’s a question of perception as to what “Flex” is.
Historically, Flex has been an application framework centered around
components. The equivalent in the JS world would probably be something like
Sencha’s UI frameworks. (i.e. ext js) or JQuery UI. So, when people hear “Flex”
Well, like I said, I'm not an expert on this stuff. My brief look at
Angular gave me the impression that it was about declarative markup for an
extensible component model. I think that's what we have too.
The key point that I'm not sure is sticking with folks is that FlexJS may
have a default fr
Hmm.
I might have been misunderstanding you.
I thought you were discussing getting FlexJS with mxml markup, data binding and
everything else to work with Angular. That’s what I don’t see as a fit.
If you mean to simply write Angular applications in AS instead of JS and
cross-compile using Falc
OK, I'll try to find time to read up on Angular. It does appear that
TypeScript works with Angular. My rudimentary understanding of this stuff
says that if you can use TS you should be able to use AS as well, but I
could certainly be wrong.
-Alex
On 7/9/14 10:43 AM, "Harbs" wrote:
>FWIW, here
FWIW, here’s some Angular-compatible components:
http://angular-ui.github.io/
http://angular-ui.github.io/bootstrap/
http://angular-ui.github.io/ng-grid/
and a whole site dedicated to cataloging Angular modules (some of it UI, and
some of it business logic):
http://ngmodules.org/
As you can see,
Angular is not really components. It’s more the glue that holds the components
together.
Basically, the selling point of Angular is how it binds javascript to HTML.
Building custom Angular components is the hardest part of using the framework
(and for the most part is not part of the framework
On 7/9/14 9:16 AM, "Harbs" wrote:
>I wouldn¹t call myself an expert on the subject, but I have had the
>opportunity to familiarize myself with both Angular and Create.js the
>past half year.
>
>Create.js makes sense to integrate into FlexJS. I¹m not sure I understand
>how Angular would/could be
I wouldn’t call myself an expert on the subject, but I have had the opportunity
to familiarize myself with both Angular and Create.js the past half year.
Create.js makes sense to integrate into FlexJS. I’m not sure I understand how
Angular would/could be integrated. It seems to me that Angular i
On 7/9/14 2:04 AM, "Erik de Bruin" wrote:
>Alex,
>
>Wow! Awesome email, if nothing else then only by weight of the bytes ;-)
I'll try to make this one shorter.
>
>I'm not sure you entirely get what I'm trying to do, but keeping an open
>mind I'm looking for ways to combine the two approaches. Y
On 09/07/14 06:56, Alex Harui wrote:
> At one point I was told that battery
> life was going to limit device cpu performance growth rates.
Medium. We're already seeing signs of people getting of the upgrade
treadmill, and moving to SIM-only deals because their current device is
'good enough'.
Man
Alex,
Wow! Awesome email, if nothing else then only by weight of the bytes ;-)
I'm not sure you entirely get what I'm trying to do, but keeping an open
mind I'm looking for ways to combine the two approaches. You seem to be
suggesting that VF2JS can exist as an option in FlexJS. We need to explor
On 7/8/14 11:22 AM, "DarkStone" wrote:
>My point is, the mobile applications made with the current Flex SDK are
>running very smooth in modern cheap mobile devices, and they will be
>running even smoother in every 3 months.
Hi Darkstone, Thanks for that info. At one point I was told that batte
Hi Alex,
One very important thing I have to point out:
The hardware of the mobile devices are improving rapidly, way faster than the
way of the desktop devices do.
In China, there are already millions of Android phones with 2GB RAM + 4 Core
CPU, under the price of $100, and I just bought a 2GB
Hi Erik,
Thanks for the list. I think this is a valuable discussion. I'm going to
respond out of order: hopefully the easiest answers first. Then at the
end is more of my continually evolving thoughts on FlexJS that may be hard
to capture from the slides.
First, keep in mind that one of the Fl
Also, between the Closure Compiler's effectiveness in optimising and
minifying code and the current state of internet speed available to users,
I think that 'application size' is not a major reason to make drastic
decisions when architecting a framework. The release version of
DatabindingTest is cu
Peter,
To be sure, I'm not criticising the work done on FlexJS - I did a fair bit
of it myself - I'm just (after Alex's insistence) stating the reasons I've
chosen to approach 'export to JS' from a different angle.
EdB
On Tue, Jul 8, 2014 at 12:57 PM, Peter Ent wrote:
> I'm sure Alex is com
I'm sure Alex is composing a longer response, but I wanted to chime in having
developed a number of beads and components of FlexJS.
FlexJS is designed to be a pay-as-go system, keeping the app size as small as
possible; even a small Flex app brings in a lot of code.
I have to agree that beads
Hi Erik,
Thank you very much for bringing this topic, it's the very topic I want to
share my thoughts on.
>3 - Strands/Beads: it forces developers to know the insides of components,
>adding a level of complexity and a steeper learning curve to the framework
>4 - forced MVC: as an option it would
OK, here goes - why I think the FlexJS concept can be improved upon (in no
particular order):
1 - there is no migration path for existing Flex applications; this will
make enterprise users reluctant to accept the new framework, even though
during development FlexJS is limiting itself because it ai
I'm not sure what you mean by "philosophical". I see more similarities
than differences between FlexJS and your approach of trying to mimic more
of the current SDK in JS. In fact, I still hope to convince you that what
you want to do is within the FlexJS charter so we can work together
instead ap
There are no technical issues per se that would need addressing to keep
FlexJS healthy. I made sure of that.
My argument is basically philosophical, and I think my ranting about it in
public would weaken FlexJS' case, so I won't.
EdB
On Thu, Jul 3, 2014 at 4:47 PM, Alex Harui wrote:
> I thin
And I've been meaning to see if anyone has invented a proxy server that
does this sort of thing.
I'm still not convinced the compiler can convert e4x to these calls. We
can if we force folks to strongly type everything, but I'd bet a lot of
existing code is not strongly-typed enough. For example
On 7/6/14 10:27 PM, "OmPrakash Muppirala" wrote:
>
>Things like public Atom, RSS feeds do require XML processing.
I would assume someone has successfully handles RSS in JS already,
probably by using whatever XML apis are there. And that is always an
option, but I believe Flash and JS XML APIs
I used the wrong link. It should have been:
https://developer.mozilla.org/en-US/docs/JXON
On Jul 7, 2014, at 8:50 AM, Harbs wrote:
> I was thinking of creating a class which stores the xml structure internally
> as javascript objects using these methods [1]
>
> Then we could build on top of th
I was thinking of creating a class which stores the xml structure internally as
javascript objects using these methods [1]
Then we could build on top of that all the standard E4X functions for accessing
nodes and attributes.
Dot notation would be complex (or impossible) to handle natively, but
On Sun, Jul 6, 2014 at 10:12 PM, Alex Harui wrote:
>
>
> On 7/6/14 9:54 PM, "OmPrakash Muppirala" wrote:
>
> >On Sun, Jul 6, 2014 at 9:49 PM, Alex Harui wrote:
> >
> >> I certainly won't stop someone from trying to implement e4x in JS. I
> >> think there may already be some attempts. I think
On 7/6/14 9:54 PM, "OmPrakash Muppirala" wrote:
>On Sun, Jul 6, 2014 at 9:49 PM, Alex Harui wrote:
>
>> I certainly won't stop someone from trying to implement e4x in JS. I
>> think there may already be some attempts. I think a significant number
>>of
>> folks use dot-path like Mark Kessler
On Sun, Jul 6, 2014 at 9:49 PM, Alex Harui wrote:
> I certainly won't stop someone from trying to implement e4x in JS. I
> think there may already be some attempts. I think a significant number of
> folks use dot-path like Mark Kessler reported and so it will still be a
> porting challenge for
I certainly won't stop someone from trying to implement e4x in JS. I
think there may already be some attempts. I think a significant number of
folks use dot-path like Mark Kessler reported and so it will still be a
porting challenge for folks to re-code to using functions.
That's why it isn't on
I use tons of dot path references for xml/e4x. And much less frequently
the inline filtering.
-Mark
On Fri, Jul 4, 2014 at 3:21 AM, Alex Harui wrote:
> There are functions, but I've seen significant use of XML as an "Object".
> IMO it is what makes e4x possible: the dot-path lookup as below:
I think it is.
Partial E4X support is better than none. We could offer support for the more
verbose form. I imagine it should be possible to do some conversions of our own
when compiling as well.
I’m not sure how to go about handling filters though.
On Jul 5, 2014, at 9:29 AM, Alex Harui wrot
I've not looked to see if the compiler does that or the runtime. I think
it is the runtime isn't it?
-Alex
On 7/4/14 10:12 AM, "Gordon Smith" wrote:
>I think this syntax is just sugar for more verbose function calls like
>
>trace(foo.children("is"))
>
>but the terse syntax is much nicer.
>
>-
I think this syntax is just sugar for more verbose function calls like
trace(foo.children("is"))
but the terse syntax is much nicer.
- Gordon
Sent from my iPad
> On Jul 4, 2014, at 12:22 AM, "Alex Harui" wrote:
>
> There are functions, but I've seen significant use of XML as an "Object".
> I
There are functions, but I've seen significant use of XML as an "Object".
IMO it is what makes e4x possible: the dot-path lookup as below:
Var foo:XML =
Trace(foo.is);
Trace(foo..a(@name=="test"));
Trace(foo..test);
But I could be wrong and there is some other way to handle this.
-Alex
On 7/
Why does it need setter/getter? E4X is all functions isn’t it?
Yeah. JSON is generally a better way to go, but some APIs are still XML and
then there’s manipulation of XML documents (which I tend to do a lot of…)
On Jul 3, 2014, at 7:53 PM, Alex Harui wrote:
> I took a quick look a while back.
I took a quick look a while back. Required getter/setter support in the
browser. And then the remaining question: will it perform? It is similar
to the AMF question. Doable, but may not be faster than switching to JSON.
-Alex
On 7/3/14 9:48 AM, "Harbs" wrote:
>Has anyone looked into writing
Has anyone looked into writing a js library to copy the functionality of E4X?
It seems to me that at least 90% of E4X could be pretty easily replicated in a
js library…
Besides namespaces, the only thing that seems hard to me is complex selectors.
On Jul 2, 2014, at 7:53 PM, Alex Harui wrote:
I think it has to be in public. This is open development. I'm hoping you
will save me time by doing so. If we are doing something we shouldn't we
should correct it now otherwise we'll waste time and energy doing more
work in that direction only to find out that customers have the same
feedback.
On 7/3/14 6:10 AM, "Igor Costa" wrote:
>@Alex
>
>I will push to my white_board for sure it's already in Apache license.
>The
>good thing about polymer it's event handling that got my attention and
>'design in mind' like we had with Flex Spark components.
>
>That's very cool about cordova, jquery
@Alex
I will push to my white_board for sure it's already in Apache license. The
good thing about polymer it's event handling that got my attention and
'design in mind' like we had with Flex Spark components.
That's very cool about cordova, jquery and createJS. It's available
anywhere?
Best
-
You want to hear that in public, or do you want to take this off list?
EdB
On Thu, Jul 3, 2014 at 7:53 AM, Alex Harui wrote:
>
>
>
> >I've been doing that as well for the last couple of years. I spent most of
> >my time getting FlexJS off the ground. But I don't agree with some of the
> >bas
gt; valid
>> > > as
>> > > > rebasing, but I think rebasing is easier and causes less trouble,
>>but
>> > you
>> > > > loose the "real-order" of commits (Which I don't really care
>>about).
>> > > >
>
>I've been doing that as well for the last couple of years. I spent most of
>my time getting FlexJS off the ground. But I don't agree with some of the
>basic assumptions and choices that FlexJS has made. I said little or
>nothing about it to give FlexJS a proper head start and to keep you and
>P
;publish' it. Is keeping the remote copy of my local branch up
> > to
> > > > date
> > > > > just a question of 'pushing' all commits to that remote branch?
> > > >
> > > >
> > > > Yes, that is correct.
> > &g
h I don't really care about).
> > >
> > > Chris
> > >
> >
> > I will let Erik decide if he wants to rebase or merge. My recommendation
> > is that, since it is a feature branch, it will be useful to retain the
> > commit history intact. So, me
>
> The namespace and MVC in in the new AS/JS framework but I don't think
> there is anything in the current FlexJS setup what would block you from
> swapping in a set of SWCs that use the mx and/or spark NS.
>
No, I'm actually swapping OUT the mx and/or Spark NS from the regular SDK.
VF2JS projec
On 7/2/14 10:05 AM, "Erik de Bruin" wrote:
>>
>> I'm still trying to figure out why your Vanilla implementation, given it
>> is going to have custom swcs, isn't just another FlexJS library. I
>>think
>> the main difference is in the reporting of missing mx/spark APIs. Is
>> there more?
>
>
>N
>
> I'm still trying to figure out why your Vanilla implementation, given it
> is going to have custom swcs, isn't just another FlexJS library. I think
> the main difference is in the reporting of missing mx/spark APIs. Is
> there more?
No, there is less. No special namespaces or MVC for the Fl
That's kind of what I would've guessed. Still makes me wonder about auto
generating the shims from your JS source.
FWIW, FlexJS is eventually going to need to find a way to warn folks about
use of E4X and a few other things in a FlexJS app. I was going to try to
inject that intelligence into Fal
; >
> > > Chris
> > >
> >
> > I will let Erik decide if he wants to rebase or merge. My
recommendation
> > is that, since it is a feature branch, it will be useful to retain the
> > commit history intact. So, merge makes sense.
> >
> > If Erik
>
> Sounds interesting. Is there any way to get more information on what
> kinds of changes are going to be made? More comments in-line.
>
I'm basically making this up as I go along, but... The workflow for
producing SWFs doesn't change at all. Hence 'Vanilla Flex'. If someone
wants to publish h
ge. My recommendation
> is that, since it is a feature branch, it will be useful to retain the
> commit history intact. So, merge makes sense.
>
> If Erik does not want to keep the commit history intact, rebase will just
> work fine.
>
> Thanks,
> Om
>
>
> >
> &
Sounds interesting. Is there any way to get more information on what
kinds of changes are going to be made? More comments in-line.
On 7/2/14 12:33 AM, "Erik de Bruin" wrote:
>Hi,
>
>I'm working on creating a way to publish vanilla Flex SDK projects to
>JavaScript on latest gen browsers. This p
Nobody will ever have to use these namespaces in their projects. The
compiler replaces the 's' and 'mx' namespaces with 'vf2js_mx' and 'vf2js_s'
in a temp copy of the project which is only used published to JS before
being deleted again. The shim components in these namespaces are there only
to get
Hi,
> 1) two new namespaces and accompanying projects in the main Flex SDK:
> vf2js_mx and vf2js_s. These namespaces will contain shim objects for (you
> guessed it) MX and Spark components.
Perhaps a friendlier namesace name? mxshim and sshim? or just mxjs and sjs?
Justin
; rebasing, but I think rebasing is easier and causes less trouble, but
> > you
> > > > loose the "real-order" of commits (Which I don't really care about).
> > > >
> > > > Chris
> > > >
> > >
> > > I will let Erik decide if he wants to rebase or merge. My
> recommendation
> > > i
ful to retain the
> > commit history intact. So, merge makes sense.
> >
> > If Erik does not want to keep the commit history intact, rebase will just
> > work fine.
> >
> > Thanks,
> > Om
> >
> >
> > >
> > >
> >
ntact. So, merge makes sense.
>
> If Erik does not want to keep the commit history intact, rebase will just
> work fine.
>
> Thanks,
> Om
>
>
> >
> >
> >
> >
> > Von: omup...@gmail.com im Auftrag von Om
. So, merge makes sense.
If Erik does not want to keep the commit history intact, rebase will just
work fine.
Thanks,
Om
>
>
>
>
> Von: omup...@gmail.com im Auftrag von OmPrakash
> Muppirala
> Gesendet: Mittwoch, 2. Juli 2014 10:25
> An: dev@flex.apache.or
_
Von: omup...@gmail.com im Auftrag von OmPrakash Muppirala
Gesendet: Mittwoch, 2. Juli 2014 10:25
An: dev@flex.apache.org
Betreff: Re: New Flex to JS project
On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin wrote:
> Ok, just checking:
>
> I create a local branch, let's call it &#
that's what GIT rebase is for.
> >
> > You can think of this sort of an automated "Create-Patch, Revert, Update,
> > Apply Patch" ... if all goes well, it's just this one command, if there
> are
> > conflicts, you get the usual conflict editor you would ge
Have a look at this ... I think it explains things quite well.
https://www.youtube.com/watch?v=cSf8cO0WB4o
Chris
Von: Erik de Bruin
Gesendet: Mittwoch, 2. Juli 2014 10:07
An: dev@flex.apache.org
Betreff: Re: New Flex to JS project
Ok, just checking
>
> > B - In order for this to work, FalconJX needs to be part of the regular
> SDK
> > distribution.
> Why not make it an optional download via the installer ant script /
> installer?
>
Because that is just what this project needs, more complexity.
EdB
--
Ix Multimedia Software
Jan Luykenst
y Patch" ... if all goes well, it's just this one command, if there are
> conflicts, you get the usual conflict editor you would get anyway if you
> created conflicts on develop.
>
> Chris
>
>
> ____________
> Von: Erik de Bruin
> Ge
Hi,
> A - I would very much like to work in the 'develop' branches of the
> projects involved
Would be better if you work in a branch, if you;re worried about getting out of
date just merge develop into your branch every now and then. Git tools eg
source tree can make this easier for you.
> B
u
created conflicts on develop.
Chris
Von: Erik de Bruin
Gesendet: Mittwoch, 2. Juli 2014 09:50
An: dev@flex.apache.org
Betreff: Re: New Flex to JS project
Hi Chris,
Thanks for the feedback.
I'm talking about FalconJX, not Falcon. The latter is th
o develop.
>
> Chris
>
> Von: Erik de Bruin
> Gesendet: Mittwoch, 2. Juli 2014 09:33
> An: dev@flex.apache.org
> Betreff: New Flex to JS project
>
> Hi,
>
> I'm working on creating a way to publish vanilla Flex SDK project
he feature is finished, you merge it back
to develop.
Chris
Von: Erik de Bruin
Gesendet: Mittwoch, 2. Juli 2014 09:33
An: dev@flex.apache.org
Betreff: New Flex to JS project
Hi,
I'm working on creating a way to publish vanilla Flex SDK projects t
Hi,
I'm working on creating a way to publish vanilla Flex SDK projects to
JavaScript on latest gen browsers. This project consists of several sub
projects, and I'm wondering what is the best way forward with regard to
contributing them:
1) two new namespaces and accompanying projects in the main
72 matches
Mail list logo
