Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

[piotrz]

Hi Josh,

Yes it was working for me while ago. Let me try later today my time with
Alex's instruction. I hope it will be as smooth as it was previously.

Thanks,
Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/LAST-CALL-Release-FlexJS-FalconJX-0-8-0-tp61275p61731.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

[Josh Tynjala]

Just a reminder, if you think you're ​ready for a release candidate, and
you plan to use the approval scripts, now is the time to test that they're
working correctly. Running them on an actual release candidate should be
quick and painless because you should have already successfully ran the
approval scripts during the last call.

See Alex's email that I'm replying to for details about the approval
scripts.

Let's try to make this vote as smooth as possible!

- Josh

On May 11, 2017 3:35 PM, "Alex Harui"  wrote:

Approval scripts seem to be ok for falcon and flexjs.  I've just pushed
some changes so give an hour or so for CI to catch up.

To use them,
-create a new folder,
-copy the ApproveFalcon or ApproveFlexJS script from the release0.8.0
branch to that folder.
-set up your environment variables per the README.
-run Ant -e -f  -Drelease.version=0.8.0.

Folks expecting to vote on this release should be examining the release
branch builds.  When I hear two more folks have done so and think things
are ok to ship, I will create an official RC.  IMO, we need to start the
vote by Sunday in order to give the 72 hours and get some propagation on
the mirrors before the Summit.  So, if you want to announce the release
for the summit, please help by making sure we are ready to start the vote
on Sunday, whether you use these scripts or not.

https://cwiki.apache.org/confluence/display/FLEX/Release+Manager+and+Releas
e+Voter+Ant+Scripts

Thanks,
-Alex

On 5/11/17, 12:20 AM, "Alex Harui"  wrote:

>Release branches built.  I added them to the Installer (FlexJS
>ReleaseBranch).  Give it a try and report issues.
>
>I'm still checking approval scripts but have to stop for tonight.
>
>-Alex
>
>On 5/10/17, 4:02 PM, "Alex Harui"  wrote:
>
>>Release branches have been cut.  CI is trying to build them.  Please put
>>changes you want in the release in the release0.8.0 branches for
>>flex-falcon and flex-asjs.
>>
>>-Alex
>>
>>On 5/9/17, 9:35 PM, "Alex Harui"  wrote:
>>
>>>
>>>
>>>On 5/9/17, 9:16 PM, "piotrz"  wrote:
>>>
What hold us with moving forward with this?
>>>
>>>I'm playing around with how library-path works.
>>>
>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.a
>>>p
>>>a
>>>che.org%2Fthread.html%2F16c293b00937227175b08070a7b1eb62d45cd8=02%7
>>>C
>>>0
>>>1%7C%7C82d819473d794aa1ff6b08d4975e074d%7Cfa7b1b5a7b34438794aed2c178dece
>>>e
>>>1
>>>%7C0%7C0%7C636299877490843060=NHGVs1fdepBeSpiUZZwCfAhgrICy1fSkkGP4
>>>B
>>>1
>>>tHxQ8%3D=0
>>>5b5eaf9b15fa52f061@%3Cdev.flex.apache.org%3E
>>>
>>>I'm hoping to cut the release branch on my Wednesday.
>>>
>>>-Alex
>>>
>>
>

Re: FlexJS MXML ids and classNames

[piotrz]

More thinking about that we need for sure one property or pseudo property
which will resolve issue with "id" duplication, the other one for me is
something optional.

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p61729.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

[piotrz]

I just pushed fix for MDL DropDownList, but it is something temporary. It
look like I have found issue which requires from me more work and discussion
on Dev list - probably need some attention from Carlos. It is specific to
how MDL works and what changes is doing with component's containers. I will
put details into the jira soon, but this is something which can be done
after release. 

I'm ok with moving forward.

Piotr




-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/LAST-CALL-Release-FlexJS-FalconJX-0-8-0-tp61275p61728.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

[piotrz]

Alex,

I examined couple of examples and from my sight I have one issue in MDL
DropDownList which would like to resolve. I hope to get it ready today. 

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/LAST-CALL-Release-FlexJS-FalconJX-0-8-0-tp61275p61727.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: FlexJS MXML ids and classNames

[piotrz]

Yep I agree with Harbs and Josh as for not touch at all id and maybe
introduce another two.

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p61726.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: FlexJS MXML ids and classNames

[Harbs]

Going along these lines:

id could have the same behavior as today.
localID could only apply to the mxml.
globalID could only apply to the HTML and would be checked by the compiler for 
uniqueness.

> On May 21, 2017, at 11:59 AM, Josh Tynjala  wrote:
> 
> I'm thinking my proposal of the name globalID is better than htmlID.
> Calling it globalID would allow us to use it on the SWF side too. For
> instance, someone could write some kind of utility function that provides
> functionality similar to document.getElementById() that works
> cross-platform to return a FlexJS component.
> 
> - Josh
> 
> On May 21, 2017 8:44 AM, "Josh Tynjala"  wrote:
> 
> The more I think about it, the more I think we should keep the semantics of
> id MXML-centric. It should create a member variable on the class like it
> always has, but it should not set the id on the HTML element. Instead, we
> should add a separate property for the HTML element's id. Maybe htmlID,
> maybe globalID.
> 
> Let's not change a core behavior of id in the MXML language. MXML id has
> been established to mean something in Flex (and Feathers too!) for over a
> decade. Let's not break that without a better reason. An MXML file will
> mostly contain high level components, rather than wrappers for specific
> HTML elements (even if there are some), so I think it's fair to expect
> developers to think in a different context for MXML and understand that id
> in MXML doesn't translate to id in HTML.
> 
> - Josh
> 
> On May 21, 2017 7:58 AM, "Alex Harui"  wrote:
> 
> 
> 
> On 5/21/17, 1:38 AM, "yishayw"  wrote:
> 
>> I like the idea. Sencha follows a similar pattern as far as I remember. I
>> don't like mxmlID. Everything in MXML is MXML. I would go with 'localId',
>> for the one that doesn't translate to HTML, and 'id' for the one that
>> does.
>> Also, there's nothing preventing an AS3 class from accessing the so called
>> 'mxmlID'.
> 
> I don't care too much what we call this property, but I cannot think of a
> scenario where someone would write 'mxmlID' from an AS3 class.  Instead, I
> think you will always access the referenced object by its assigned name.
> IOW:
> 
> Foo.mxml 
>
>
>
> 
> 
> 
> Means that you will write "bar.someProperty".  In fact, it might be
> possible for "mxmlID" or "localID" to be a pseudo-property and not
> actually a property on the object.  We already do this for "includeIn" and
> "excludeFrom" in states.  These properties are truly MXML-only and not
> ever set on the object.
> 
> If we want to be more descriptive, we could call it "documentID" or even
> "documentVariableName" or "mxmlDocumentVariableName" which is actually
> what it does.
> 
> Thoughts?
> -Alex

Re: FlexJS MXML ids and classNames

[Josh Tynjala]

I'm thinking my proposal of the name globalID is better than htmlID.
Calling it globalID would allow us to use it on the SWF side too. For
instance, someone could write some kind of utility function that provides
functionality similar to document.getElementById() that works
cross-platform to return a FlexJS component.

- Josh

On May 21, 2017 8:44 AM, "Josh Tynjala"  wrote:

The more I think about it, the more I think we should keep the semantics of
id MXML-centric. It should create a member variable on the class like it
always has, but it should not set the id on the HTML element. Instead, we
should add a separate property for the HTML element's id. Maybe htmlID,
maybe globalID.

Let's not change a core behavior of id in the MXML language. MXML id has
been established to mean something in Flex (and Feathers too!) for over a
decade. Let's not break that without a better reason. An MXML file will
mostly contain high level components, rather than wrappers for specific
HTML elements (even if there are some), so I think it's fair to expect
developers to think in a different context for MXML and understand that id
in MXML doesn't translate to id in HTML.

- Josh

On May 21, 2017 7:58 AM, "Alex Harui"  wrote:



On 5/21/17, 1:38 AM, "yishayw"  wrote:

>I like the idea. Sencha follows a similar pattern as far as I remember. I
>don't like mxmlID. Everything in MXML is MXML. I would go with 'localId',
>for the one that doesn't translate to HTML, and 'id' for the one that
>does.
>Also, there's nothing preventing an AS3 class from accessing the so called
>'mxmlID'.

I don't care too much what we call this property, but I cannot think of a
scenario where someone would write 'mxmlID' from an AS3 class.  Instead, I
think you will always access the referenced object by its assigned name.
IOW:

 Foo.mxml 






Means that you will write "bar.someProperty".  In fact, it might be
possible for "mxmlID" or "localID" to be a pseudo-property and not
actually a property on the object.  We already do this for "includeIn" and
"excludeFrom" in states.  These properties are truly MXML-only and not
ever set on the object.

If we want to be more descriptive, we could call it "documentID" or even
"documentVariableName" or "mxmlDocumentVariableName" which is actually
what it does.

Thoughts?
-Alex

Re: FlexJS MXML ids and classNames

[Josh Tynjala]

The more I think about it, the more I think we should keep the semantics of
id MXML-centric. It should create a member variable on the class like it
always has, but it should not set the id on the HTML element. Instead, we
should add a separate property for the HTML element's id. Maybe htmlID,
maybe globalID.

Let's not change a core behavior of id in the MXML language. MXML id has
been established to mean something in Flex (and Feathers too!) for over a
decade. Let's not break that without a better reason. An MXML file will
mostly contain high level components, rather than wrappers for specific
HTML elements (even if there are some), so I think it's fair to expect
developers to think in a different context for MXML and understand that id
in MXML doesn't translate to id in HTML.

- Josh

On May 21, 2017 7:58 AM, "Alex Harui"  wrote:



On 5/21/17, 1:38 AM, "yishayw"  wrote:

>I like the idea. Sencha follows a similar pattern as far as I remember. I
>don't like mxmlID. Everything in MXML is MXML. I would go with 'localId',
>for the one that doesn't translate to HTML, and 'id' for the one that
>does.
>Also, there's nothing preventing an AS3 class from accessing the so called
>'mxmlID'.

I don't care too much what we call this property, but I cannot think of a
scenario where someone would write 'mxmlID' from an AS3 class.  Instead, I
think you will always access the referenced object by its assigned name.
IOW:

 Foo.mxml 






Means that you will write "bar.someProperty".  In fact, it might be
possible for "mxmlID" or "localID" to be a pseudo-property and not
actually a property on the object.  We already do this for "includeIn" and
"excludeFrom" in states.  These properties are truly MXML-only and not
ever set on the object.

If we want to be more descriptive, we could call it "documentID" or even
"documentVariableName" or "mxmlDocumentVariableName" which is actually
what it does.

Thoughts?
-Alex

Re: FlexJS MXML ids and classNames

[piotrz]

Alex,

You mean that I will not be able call property in AS3 like this ?






I'm not following where the problem is.

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p61722.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: FlexJS MXML ids and classNames

[Harbs]

I don’t really what we call this, but I think the following is important:

I would like an option for the following:
1. Ability to set an id in mxml-only
2. Ability set HTML ids
3. Have the compiler check that HTML ids are not used more than once.

> On May 21, 2017, at 10:58 AM, Alex Harui  wrote:
> 
> 
> 
> On 5/21/17, 1:38 AM, "yishayw"  wrote:
> 
>> I like the idea. Sencha follows a similar pattern as far as I remember. I
>> don't like mxmlID. Everything in MXML is MXML. I would go with 'localId',
>> for the one that doesn't translate to HTML, and 'id' for the one that
>> does.
>> Also, there's nothing preventing an AS3 class from accessing the so called
>> 'mxmlID'.
> 
> I don't care too much what we call this property, but I cannot think of a
> scenario where someone would write 'mxmlID' from an AS3 class.  Instead, I
> think you will always access the referenced object by its assigned name.
> IOW:
> 
> Foo.mxml  
>
>
>
> 
> 
> 
> Means that you will write "bar.someProperty".  In fact, it might be
> possible for "mxmlID" or "localID" to be a pseudo-property and not
> actually a property on the object.  We already do this for "includeIn" and
> "excludeFrom" in states.  These properties are truly MXML-only and not
> ever set on the object.
> 
> If we want to be more descriptive, we could call it "documentID" or even
> "documentVariableName" or "mxmlDocumentVariableName" which is actually
> what it does.
> 
> Thoughts?
> -Alex
> 

Re: FlexJS MXML ids and classNames

[Alex Harui]

On 5/21/17, 1:38 AM, "yishayw"  wrote:

>I like the idea. Sencha follows a similar pattern as far as I remember. I
>don't like mxmlID. Everything in MXML is MXML. I would go with 'localId',
>for the one that doesn't translate to HTML, and 'id' for the one that
>does.
>Also, there's nothing preventing an AS3 class from accessing the so called
>'mxmlID'.

I don't care too much what we call this property, but I cannot think of a
scenario where someone would write 'mxmlID' from an AS3 class.  Instead, I
think you will always access the referenced object by its assigned name.
IOW:

 Foo.mxml   






Means that you will write "bar.someProperty".  In fact, it might be
possible for "mxmlID" or "localID" to be a pseudo-property and not
actually a property on the object.  We already do this for "includeIn" and
"excludeFrom" in states.  These properties are truly MXML-only and not
ever set on the object.

If we want to be more descriptive, we could call it "documentID" or even
"documentVariableName" or "mxmlDocumentVariableName" which is actually
what it does.

Thoughts?
-Alex

Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

[Alex Harui]

On 5/21/17, 7:41 AM, "Yishay Weiss"  wrote:

>Also, I don’t see changes in Framework reflected in test project.

What kinds of changes?  Adding a new bead and changing CSS may not be
picked up by FB.  But when I changed Label.as to add "foo" to every text
property, that change showed up in my test app as I expected.

-Alex

Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

[Alex Harui]

On 5/21/17, 7:41 AM, "Yishay Weiss"  wrote:

>I had to change \frameworks\flex-config.xml and remove sfw-
>from  and . Otherwise
>there’s no code hinting in new FB project. Shouldn’t that be the default
>configuration?

I'm not sure we got enough responses to that idea, but that's fine with
me.  I think if you make the changes to
frameworks/flex-config-template.xml and air-config-template.xml that will
get you the results you want.

-Alex

Re: [ApacheCon/FlexJS Summit] FlexJS 1.0 Discussion Round - Summary

[PKumar]

Peter,

As compare to regular FlexSDK , there is no way to select any file from
file system and adding file type filter on selection. Also no way to open
FileSave dialogue box.

On 21-May-2017 7:18 PM, "Peter Ent-2 [via Apache Flex Development]" <
ml+s247n61714...@n4.nabble.com> wrote:

> The FlexJS Storage package address some storage concerns. It provides file
> handling when run via AIR and on mobile devices via Cordova. Since there
> are sandboxing issues with the Flash Player, I'm not sure what else we can
> do there besides local storage.
>
> ‹peter
>
> On 5/21/17, 7:25 AM, "PKumar" <[hidden email]
> > wrote:
>
> >FileHandling  can also be a option in the list. Right now FlexJS not
> >having
> >any file handling capabilities.
> >
> >On 20-May-2017 5:45 PM, "yishayw [via Apache Flex Development]" <
> >[hidden email] >
> wrote:
> >
> >> Items 1-9 were considered musts.
> >>
> >> Fontkit library port (item 7) made it to the list because it was
> >>blocking
> >> Maven builds. I think Chris has found a workaround, so maybe we can
> >>strike
> >> that off.
> >>
> >> Post meeting there was some agreement that a better looking default
> >>theme
> >> was also a must. Leonidas said he would provide us with the graphics.
> >>That
> >> would be very helpful in my opinion.
> >>
> >>
> >> --
> >> If you reply to this email, your message will be added to the
> discussion
> >> below:
> >>
> >>https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fapache-fl
> >>ex-development.247.n4.nabble=02%7C01%7C%7C9e768268022a4555dcd008
>
> >>d4a03dfbb9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63630963545957906
>
> >>9=D4m8GDMEUC5WcEpHcxKSDOGHnc4MXZx3fhT4ksecVw0%3D=0.
> >> com/ApacheCon-FlexJS-Summit-FlexJS-1-0-Discussion-Round-
> >> Summary-tp61700p61703.html
> >> To start a new topic under Apache Flex Development, email
> >> [hidden email] 
> >> To unsubscribe from Apache Flex Development, click here
> >>
> >> http%3A%2F%2Fapache-f
> >>lex-development.247.n4.nabble.com%2Ftemplate%2FNamlServlet.jtp%3Fmacr
>
> >>o%3Dunsubscribe_by_code%26node%3D1%26code%3DcHJhc2hha3VtYXJAZ21haWwuY29tf
>
> >>DF8LTU0MTcyMzE2NA=02%7C01%7C%7C9e768268022a4555dcd008d4a03dfbb9%7Cfa
>
> >>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636309635459579069=FGQ9vpd
>
> >>yMvICZ4dTpGxOsYF0hWp%2FMPg6x%2FwB3thsayM%3D=0==>
> >> .
> >> NAML
> >>
> >> http%3A%2F%2Fapache-f
> >>lex-development.247.n4.nabble.com%2Ftemplate%2FNamlServlet.jtp%3Fmacr
>
> >>o%3Dmacro_viewer%26id%3Dinstant_html%2521nabble%253Aemail.naml%26base%3Dn
>
> >>abble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNames
>
> >>pace-nabble.view.web.template.NodeNamespace%26breadcrumbs%3Dnotify_subscr
>
> >>ibers%2521nabble%253Aemail.naml-instant_emails%2521nabble%253Aemail.naml-
>
> >>send_instant_email%2521nabble%253Aemail.naml=02%7C01%7C%7C9e76826802
>
> >>2a4555dcd008d4a03dfbb9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63630
>
> >>9635459579069=VVuCGtlA2uJ2eu4LI9uKVYKFElfHNdBz0uQpNe%2F%2BBGY%3D
>
> >>served=0>
> >>
> >
> >
> >
> >
> >--
> >View this message in context:
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fapache-fle
> >x-development.247.n4.nabble.com%2FApacheCon-FlexJS-Summit-FlexJS-1-0-D
>
> >iscussion-Round-Summary-tp61700p61713.html=02%7C01%7C%7C9e768268022a4
>
> >555dcd008d4a03dfbb9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636309635
>
> >459579069=BTZ1%2FXsfjGT7XLQEFFvVz5L%2F1F0XIqB5BzxxaVT0%2Fb0%3D
>
> >ved=0
> >Sent from the Apache Flex Development mailing list archive at Nabble.com.
>
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://apache-flex-development.247.n4.nabble.
> com/ApacheCon-FlexJS-Summit-FlexJS-1-0-Discussion-Round-
> Summary-tp61700p61714.html
> To start a new topic under Apache Flex Development, email
> ml+s247n1...@n4.nabble.com
> To unsubscribe from Apache Flex Development, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/ApacheCon-FlexJS-Summit-FlexJS-1-0-Discussion-Round-Summary-tp61700p61717.html
Sent from the Apache Flex Development mailing 

RE: [LAST CALL] Release FlexJS/FalconJX 0.8.0

[Yishay Weiss]

I had to change \frameworks\flex-config.xml and remove sfw- from 
 and . Otherwise there’s no code 
hinting in new FB project. Shouldn’t that be the default configuration?

From: Alex Harui
Sent: Saturday, May 20, 2017 4:51 PM
To: dev@flex.apache.org
Subject: Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

"Pulled changes" as in syncing up the repo or grabbing the release CI
build?

Looks like the CI build was stuck, maybe for 3 days!  I've just unstuck
it.  It should take a couple of hours to finish building the latest from
the release branches.

If you are working from the repos, make sure you compiler jars are up to
date in the FlexJS SDK that FB is using.

-Alex

On 5/20/17, 7:01 AM, "yishayw"  wrote:

>I just pulled the changes and tried to build using FB. I'm getting this
>
>1319: unknown configuration variable 'compiler.targets'.
>C:\dev\flexjs\flex-asjs\frameworks\projects\Core\src\main\config\compile-s
>wf-config.xml
>(line: 25)
>
>So Core doesn't build.
>
>
>
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FLAST-CALL-Release-FlexJS-FalconJX-0-
>8-0-tp61275p61704.html=02%7C01%7C%7C82d9b3c3bd5a43be7d9b08d49f8a9d10%
>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636308865070833457=Cthw
>oTulwCSM4Y8cjtNNiZosHUyCNd24BhNDjCm9vNg%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

RE: [LAST CALL] Release FlexJS/FalconJX 0.8.0

[Yishay Weiss]

Also, I don’t see changes in Framework reflected in test project.

From: Alex Harui
Sent: Saturday, May 20, 2017 4:51 PM
To: dev@flex.apache.org
Subject: Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

"Pulled changes" as in syncing up the repo or grabbing the release CI
build?

Looks like the CI build was stuck, maybe for 3 days!  I've just unstuck
it.  It should take a couple of hours to finish building the latest from
the release branches.

If you are working from the repos, make sure you compiler jars are up to
date in the FlexJS SDK that FB is using.

-Alex

On 5/20/17, 7:01 AM, "yishayw"  wrote:

>I just pulled the changes and tried to build using FB. I'm getting this
>
>1319: unknown configuration variable 'compiler.targets'.
>C:\dev\flexjs\flex-asjs\frameworks\projects\Core\src\main\config\compile-s
>wf-config.xml
>(line: 25)
>
>So Core doesn't build.
>
>
>
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FLAST-CALL-Release-FlexJS-FalconJX-0-
>8-0-tp61275p61704.html=02%7C01%7C%7C82d9b3c3bd5a43be7d9b08d49f8a9d10%
>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636308865070833457=Cthw
>oTulwCSM4Y8cjtNNiZosHUyCNd24BhNDjCm9vNg%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [ApacheCon/FlexJS Summit] FlexJS 1.0 Discussion Round - Summary

[Peter Ent]

The FlexJS Storage package address some storage concerns. It provides file
handling when run via AIR and on mobile devices via Cordova. Since there
are sandboxing issues with the Flash Player, I'm not sure what else we can
do there besides local storage.

‹peter

On 5/21/17, 7:25 AM, "PKumar"  wrote:

>FileHandling  can also be a option in the list. Right now FlexJS not
>having
>any file handling capabilities.
>
>On 20-May-2017 5:45 PM, "yishayw [via Apache Flex Development]" <
>ml+s247n6170...@n4.nabble.com> wrote:
>
>> Items 1-9 were considered musts.
>>
>> Fontkit library port (item 7) made it to the list because it was
>>blocking
>> Maven builds. I think Chris has found a workaround, so maybe we can
>>strike
>> that off.
>>
>> Post meeting there was some agreement that a better looking default
>>theme
>> was also a must. Leonidas said he would provide us with the graphics.
>>That
>> would be very helpful in my opinion.
>>
>>
>> --
>> If you reply to this email, your message will be added to the discussion
>> below:
>> 
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl
>>ex-development.247.n4.nabble=02%7C01%7C%7C9e768268022a4555dcd008
>>d4a03dfbb9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63630963545957906
>>9=D4m8GDMEUC5WcEpHcxKSDOGHnc4MXZx3fhT4ksecVw0%3D=0.
>> com/ApacheCon-FlexJS-Summit-FlexJS-1-0-Discussion-Round-
>> Summary-tp61700p61703.html
>> To start a new topic under Apache Flex Development, email
>> ml+s247n1...@n4.nabble.com
>> To unsubscribe from Apache Flex Development, click here
>> 
>>>lex-development.247.n4.nabble.com%2Ftemplate%2FNamlServlet.jtp%3Fmacr
>>o%3Dunsubscribe_by_code%26node%3D1%26code%3DcHJhc2hha3VtYXJAZ21haWwuY29tf
>>DF8LTU0MTcyMzE2NA=02%7C01%7C%7C9e768268022a4555dcd008d4a03dfbb9%7Cfa
>>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636309635459579069=FGQ9vpd
>>yMvICZ4dTpGxOsYF0hWp%2FMPg6x%2FwB3thsayM%3D=0==>
>> .
>> NAML
>> 
>>>lex-development.247.n4.nabble.com%2Ftemplate%2FNamlServlet.jtp%3Fmacr
>>o%3Dmacro_viewer%26id%3Dinstant_html%2521nabble%253Aemail.naml%26base%3Dn
>>abble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNames
>>pace-nabble.view.web.template.NodeNamespace%26breadcrumbs%3Dnotify_subscr
>>ibers%2521nabble%253Aemail.naml-instant_emails%2521nabble%253Aemail.naml-
>>send_instant_email%2521nabble%253Aemail.naml=02%7C01%7C%7C9e76826802
>>2a4555dcd008d4a03dfbb9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63630
>>9635459579069=VVuCGtlA2uJ2eu4LI9uKVYKFElfHNdBz0uQpNe%2F%2BBGY%3D
>>served=0>
>>
>
>
>
>
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FApacheCon-FlexJS-Summit-FlexJS-1-0-D
>iscussion-Round-Summary-tp61700p61713.html=02%7C01%7C%7C9e768268022a4
>555dcd008d4a03dfbb9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636309635
>459579069=BTZ1%2FXsfjGT7XLQEFFvVz5L%2F1F0XIqB5BzxxaVT0%2Fb0%3D
>ved=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [ApacheCon/FlexJS Summit] FlexJS 1.0 Discussion Round - Summary

[PKumar]

FileHandling  can also be a option in the list. Right now FlexJS not having
any file handling capabilities.

On 20-May-2017 5:45 PM, "yishayw [via Apache Flex Development]" <
ml+s247n6170...@n4.nabble.com> wrote:

> Items 1-9 were considered musts.
>
> Fontkit library port (item 7) made it to the list because it was blocking
> Maven builds. I think Chris has found a workaround, so maybe we can strike
> that off.
>
> Post meeting there was some agreement that a better looking default theme
> was also a must. Leonidas said he would provide us with the graphics. That
> would be very helpful in my opinion.
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://apache-flex-development.247.n4.nabble.
> com/ApacheCon-FlexJS-Summit-FlexJS-1-0-Discussion-Round-
> Summary-tp61700p61703.html
> To start a new topic under Apache Flex Development, email
> ml+s247n1...@n4.nabble.com
> To unsubscribe from Apache Flex Development, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/ApacheCon-FlexJS-Summit-FlexJS-1-0-Discussion-Round-Summary-tp61700p61713.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: FlexJS MXML ids and classNames

[yishayw]

I like the idea. Sencha follows a similar pattern as far as I remember. I
don't like mxmlID. Everything in MXML is MXML. I would go with 'localId',
for the one that doesn't translate to HTML, and 'id' for the one that does.
Also, there's nothing preventing an AS3 class from accessing the so called
'mxmlID'.



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p61710.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: FlexJS MXML ids and classNames

[piotrz]

Hi Justin,

I just checked and yes I'm running into exactly same issue.

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p61709.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.