Re: AMFPHP support for FlexJS

[Greg Dove]

As Alex mentioned, I think things should be ready to support AMF (and/or
potential other serialization/deserialization approaches) via Reflection.

I already added support for registerClassAlias,  getClassByAlias, and (new)
getAliasByClass,in the reflection package - note that I did not put these
in the network project (which would have been consistent with flash.net.*)
because for js it seemed to me that they would always be used in
conjunction with Reflection API. But if others feel strongly about this,
feel free to change that.

I have not checked whether falcon handles [RemoteClass] meta to generate
registerClassAlias calls automatically. If it does then perhaps this needs
to be considered for js to use the new reflection function for this same
support.

Current reflection support will also allow for checking for [Transient]
metadata to exclude those readwrite accessors or variables from the set of
fields determined for serialization via reflection.

What we do not currently have is something analogous to IExternalizable,
but perhaps that could be for later (I think I may have used this only once
in the past, perhaps others use it more).

cheers,
Greg



On Fri, Oct 28, 2016 at 7:38 AM, OK  wrote:

> Hey Carlos,
>
>
> Carlos Rovira wrote
> > Hi Olaf, I think is more about efficiency and optimization. AMF is
> binary,
> > more compacted and faster that any other method I known out there.
>
> Yes, Flex/AMF is definately faster and I remember the discussions years ago
> about AMF regarding performance. But even if it's faster I'm not sure if
> you
> really notice it cause often there're other bottle necks that slow down
> things.
> More over I think it depends on the use case to be really profit by the
> performance lead of AMF.
>
> Don't get me wrong, it would be great if FlexJS will support AMF but I'd
> also like to say that the current lack of AMF support is no show stopper
> that makes it impossible to use FlexJS.
> In best case people maybe could just add a facade on top of their current
> backend to be able to speak JSON over http.
>
> Anyway, you are my MDL super hero, thanks again for working on it !!! ;-)
>
> Thanks,
> Olaf
>
>
>
>
>
> --
> View this message in context: http://apache-flex-
> development.247.n4.nabble.com/AMFPHP-support-for-FlexJS-
> tp56066p56087.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: AMFPHP support for FlexJS

[Fréderic Cox]

I have to disagree with Olaf here. In our company the entire backend is using 
AMFPHP. Changing that to JSON and changing the frontend code as well is not a 
viable option. If AMFPHP works in FlexJS there would not be any changed 
required on both ends. Just making a point here that use cases indeed differ 
but for some companies it might be a key point in deciding wether or not to go 
forward with FlexJS.

Verstuurd vanaf mijn iPhone

> Op 27 okt. 2016 om 20:38 heeft OK  het volgende 
> geschreven:
> 
> Hey Carlos,
> 
> 
> Carlos Rovira wrote
>> Hi Olaf, I think is more about efficiency and optimization. AMF is binary,
>> more compacted and faster that any other method I known out there. 
> 
> Yes, Flex/AMF is definately faster and I remember the discussions years ago
> about AMF regarding performance. But even if it's faster I'm not sure if you
> really notice it cause often there're other bottle necks that slow down
> things.
> More over I think it depends on the use case to be really profit by the
> performance lead of AMF.
> 
> Don't get me wrong, it would be great if FlexJS will support AMF but I'd
> also like to say that the current lack of AMF support is no show stopper
> that makes it impossible to use FlexJS.
> In best case people maybe could just add a facade on top of their current
> backend to be able to speak JSON over http.
> 
> Anyway, you are my MDL super hero, thanks again for working on it !!! ;-)
> 
> Thanks,
> Olaf
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://apache-flex-development.247.n4.nabble.com/AMFPHP-support-for-FlexJS-tp56066p56087.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Problems with the Installer

[OK]

Alex Harui wrote
> OK, pushed a fix.  New nightly build should be available in about 45
> minutes.

Works, thanks Alex!

Olaf



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Problems-with-the-Installer-tp56020p56090.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Setting source to external CSS does not work

[Alex Harui]

On 10/27/16, 11:55 AM, "Fréderic Cox"  wrote:

>
>and I would now like to style it using our company's main website
>(replaced
>it with {companyDomain}.com for this thread). I tried:
>
>https://www.static.
>{companyDomain}.com/styles/master-v2.2-99371.css" />
>
>but then I get the following error:
>
>/Users/frederic/Desktop/Personal/Flex/FlexJSTest/src/FlexJSTest.mxml:14
>
>Can't find 'source' file
>"/Users/frederic/Desktop/Personal/Flex/FlexJSTest/src/https:/www.static.{c
>ompanyDomain}.com/styles/master-v2.2-99371.css".
>
>source="https://www.static.{companyDomain}.com/styles/master-v2.2-99371.cs
>s"
>/>
>
>  ^
>
>Is it not supposed to work like this? It would be nice if this worked

The compiler isn't set up make get css over the network right now.  It
might be possible.  Feel free to file a feature request.

If you make a local copy of it, it should work.

Also, you can grab the nightly build and try the -html-template option.
Get the template from templates/js-index-template.html and add your

Setting source to external CSS does not work

[Fréderic Cox]

I am creating my first projects in Flex 0.7.0 tonight.

I must say the installation guidelines from the WIKI are very clear and I
was set-up very quickly.

I encountered a first "issue", is it the right place to report/ask about it
here? Or should I use something like stackoverflow for my questions?

Anyway I created a simple view:

































and I would now like to style it using our company's main website (replaced
it with {companyDomain}.com for this thread). I tried:

https://www.static.
{companyDomain}.com/styles/master-v2.2-99371.css" />

but then I get the following error:

/Users/frederic/Desktop/Personal/Flex/FlexJSTest/src/FlexJSTest.mxml:14

Can't find 'source' file
"/Users/frederic/Desktop/Personal/Flex/FlexJSTest/src/https:/www.static.{companyDomain}.com/styles/master-v2.2-99371.css".

https://www.static.{companyDomain}.com/styles/master-v2.2-99371.css;
/>

  ^

Is it not supposed to work like this? It would be nice if this worked

Re: AMFPHP support for FlexJS

[OK]

Hey Carlos,


Carlos Rovira wrote
> Hi Olaf, I think is more about efficiency and optimization. AMF is binary,
> more compacted and faster that any other method I known out there. 

Yes, Flex/AMF is definately faster and I remember the discussions years ago
about AMF regarding performance. But even if it's faster I'm not sure if you
really notice it cause often there're other bottle necks that slow down
things.
More over I think it depends on the use case to be really profit by the
performance lead of AMF.

Don't get me wrong, it would be great if FlexJS will support AMF but I'd
also like to say that the current lack of AMF support is no show stopper
that makes it impossible to use FlexJS.
In best case people maybe could just add a facade on top of their current
backend to be able to speak JSON over http.

Anyway, you are my MDL super hero, thanks again for working on it !!! ;-)

Thanks,
Olaf





--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/AMFPHP-support-for-FlexJS-tp56066p56087.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: AMFPHP support for FlexJS

[PKumar]

I am digging in to AMFJS and tested it with AMFPHP & Blazeds. Currently i am
trying to use AMFJS functions  in FlexJS side. I am also looking the FlexSDK
RemoteObject implementation and registerclassAlias implementation, so that i
can get more information on this. 



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/AMFPHP-support-for-FlexJS-tp56066p56086.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: AMFPHP support for FlexJS

[Alex Harui]

On 10/27/16, 8:44 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Olaf, I think is more about efficiency and optimization. AMF is binary,
>more compacted and faster that any other method I known out there. in
>terms
>of usability is as well more easy to work with.
>
>I'm afraid that AMF could not be successful as JSON maybe due to people
>not
>know about the openness of the format and as well due to the way to work
>with it through typed objects. One of its advantages and maybe a
>disadventage since JSON is maybe more direct to work with (but very
>cumbersome in the end).
>

I hope to see someone, maybe Prashant, make a serious effort at porting
RemoteObject to FlexJS.  I'm not clear how much Flash-dependency there
really is other than NetConnection.  I think we've pretty much have a good
enough Reflection API in FlexJS.

I'm interested to see how efficient AMF will be in JS.  It certainly was
more efficient in Flash, but that's because the AMF conversion is done in
C code in the runtime.  For FlexJS in JS, it will be done in JS where as
JSON.parse() runs in browser code and not in JS.  So there is a chance
that JSON will be faster than AMF in JS.  JSON seems to support a
"reviver" which I think might be usable to have JSON efficiently create
the FlexJS equivalent of typed instances of Value Objects in JS.

IMO, this question will just keep being asked until we implement
RemoteObject and run some tests.

-Alex

Re: [FlexJS} When to Bead (was Re: [FlexJS] enabled property)

[Alex Harui]

On 10/27/16, 9:09 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>
>I like the Yishayw concept os adding beads in CSS. Don't know about the
>runtime cost of this, but it would allow users to configure if they want
>this or those beads for their use. If you add in the component, all is
>done
>there and people can't change it. Maybe you're the person to decide if
>this
>could be done or there's a penalty to pay that make It not viable.

You can already specify some beads like Layout and Views from CSS.  I
don't think the Basic set should do spend the cycles considering
"additionalBeads" since I think once you get into production, you should
have the option of optimizing if you know what beads you need where.  But
other component sets can.  So no decision really has to be made.  Folks
who want it can implement it in a different component set.  It might be
time for someone to start on a "kitchen-sink" component set that bakes a
lot of beads in and supports an "additionalBeads" property.

-Alex

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

[Alex Harui]

On 10/27/16, 12:56 AM, "carlos.rov...@gmail.com on behalf of Carlos
Rovira"  wrote:

>Hi,
>
>don't know how you plan to do this, but seems an important refactor and
>lots of files included.
>I suggest to do this in an "integration" branch to manage all posible
>colateral issues generated. And then as adjusted merge with develop.

I thought about having a separate branch, but didn't do it (yet).  How
does having an integration branch help?  Seems like it would just mean two
merges instead of one.  I already have other working copies of flex-asjs
on my computer so I can handle other requests for changes while the merge
is in progress.

>
>As well, I came to the discussion too much late so I don't know about the
>basic thinking of this refactor. Could you share what's behind? (now that
>you discuss it for long time)

I saw Harbs summed it up, but my take is this:

I am a code minimalist, so I am hopeful that we can implement some sort of
overloading in the compiler such that we can make it look like we have
nice clean no-flash API signature in the FlexJS APIs.  IMO, we have to
provide some sort of overloading some day anyway since otherwise,
ActionScript will fall behind other languages that do support overloading.

I believe if we can allow overloading, then you don't need pay the runtime
cost of wrapping the platform implementations.  You can just make sure the
subclasses of the platform implementations have a common API.  That means
that app developers may trip over the platform implementations more often,
but you will be glad we offered you this option if your app becomes too
big or too slow.

IMO, it is just more efficient to talk to someone who has a different
native language but understands enough English (the common API) than to
have to use another person as a translator (which effectively wraps the
person you want to talk to).  But yes, you have to be careful in your
choice of words (adding new APIs or using old Flash APIs) since those
words might have meaning to the non-English speaker.  (I was working with
folks from Japan once and mentioned how I liked Tacos for lunch.  They
were surprised at first because Tako means Octopus in Japanese which isn't
nearly as well liked).

Here are some scenarios:

If you are porting existing Flash-based code to FlexJS, you want to get a
good idea of how many changes you have to make.  At the time Harbs started
on the port, the workflow was to look for "import flash" in your code and
replace those imports with FlexJS imports (if they existed) and then just
try compiling against the FlexJS SWCs for SWF, since compiling a SWF is
what the IDE knows how to do.  The problem with that is that a simple
reference to, for example, the "scaleX" property is not caught by this
workflow.  Clearly, if you take the time to create wrappers for the
components that only implement the FlexJS APIs that work on both
platforms, then the compiler would catch that you are using "scaleX".

But we are looking into upgrading the compiler so that you can run the JS
cross-compile directly as well as the SWF compile from the IDE, so the
problems panel should show that "scaleX" is missing in the cross-compile,
and then you don't need to wrap.

Similarly, if someday someone wanted to implement a "buttonMode" property
on a Button and didn't know the Flash implementation already used it, you
will get an error and have to use a different property name.  You wouldn't
if you are working against wrapped components.

Really, there is no right or wrong way.  I am just certain that we "must"
have a component set that does not have any extra code spent on wrapping
implementations if we can implement overloading propertly, or on parameter
validation, or anything else you don't need in production.  It is totally
fine to have other component sets that wrap things, aggregate beads, etc
to make development or migration easier, but the low-level must truly be
low-level if you are trying to fit your production version into some
metric of code size, download size, startup time performance.  The
framework should not be to blame if you can't fit.  The smaller and faster
we make it, the better off our customers will be.  Even an additional line
of code adds up over time.

HTH,
-Alex

Re: [FlexJS} When to Bead (was Re: [FlexJS] enabled property)

[Carlos Rovira]

Hi Alex,

I like the Yishayw concept os adding beads in CSS. Don't know about the
runtime cost of this, but it would allow users to configure if they want
this or those beads for their use. If you add in the component, all is done
there and people can't change it. Maybe you're the person to decide if this
could be done or there's a penalty to pay that make It not viable.

@Yishayw, Disable bead is not yet finished, you said it need a way to
change. I was implementing it but found problems. I'll return to it as soon
as possible to change it. Regarding SWF, I'm not centering my efforts
there, since MDL is mainly HTML, but I'm reserving space to implement SWF
more later, but it will be much more complicated, since it will requiere
create all the MDL visuals in flash. I think for now there's so much work
in HTML - MDL.



2016-10-27 17:41 GMT+02:00 Alex Harui :

>
>
> On 10/27/16, 12:48 AM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira"  carlos.rov...@codeoscopic.com> wrote:
>
> >Thanks,
> >
> >I was not thinking this from that point of view. Maybe in MDL has sense to
> >include majority of beads since it's a concrete implementation of visuals:
> >Material Design Lite
> >But don't know if we could have a base control (ButtonBase...for example
> >but doesn't like too much that name) and then another (the Button *actual
> >class*) that instantiates ButtonEffect and Disable beads
> >
> >btw, if you notice, I remove the "Bead" ending in my beads, since I think
> >is less verbose and the mxml is pretty descriptive (those are parte of
> >js:beads).
>
> It does look fine in MXML, but I worry about how to find them in ASDoc.
> That's why I want to try to create a smarter doc app for FlexJS where we
> mark classes with @bead and @component so folks can filter better.
>
> >As well I implemented effects with boolean flags. I have to make different
> >beads for different controls since are effect "per-control", with some to
> >them common and available in an MDLEffect bead that the rest extend from.
>
> IMO, it is all a trade-off.  The Basic set will have everything broken out
> into beads, but I fully expect the most popular first-time-user component
> set will have lots of beads aggregated into it to make developing your POC
> less verbose.  So yes, you can break stuff out into pieces inside MDL as
> well, but realize that is another trade-off.  An aggregation of beads will
> be heavier and slower than just baking some code into the component, but
> if you aggregate beads then you can factor them out later if you aren't
> using.
>
> -Alex
>
>


-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es


Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

[Alex Harui]

On 10/27/16, 12:15 AM, "Harbs"  wrote:

>I had an idea last night:
>
>Instead of having two different namespaces for wrapped and unwrapped
>components, what about making it a compiler option?

Actually, it appears that we can have two SWCs with the same namespaces.
The most recently compiled one will win unless we start specifying each
SWC in flex-config.xml.  Currently we only specify a folder so all SWCs
are considered.  IMO, specifying a folder makes life easier for IDE and
Ant users and I can manage working with a list of specific SWCs.

>
>The primary difference between the two is:
>1. The base class is different.
>2. References in platform-specific code to the platform-specific
>implementation when needed.
>
>#1 can be resolved by conditional compilation blocks (such as
>COMPILE::OPTIMIZE_PERFORMANCE and COMPILE::OPTIMIZE_COMPATIBILITY)

Maybe, but I would think that would make the source code hard to read with
so many options.

>#2 can be resolved by having a variable which points to the
>implementation (and typed as an Object) So for wrapped components,
>myComponents.impl (or whatever we’d call it) would be
>HTMLElementWrapper.$displayObject and for subclassed components it would
>be “this”. For HTML, it would be element, etc.

I want the existing code in Basic to work with out an additional
variables.  IMO, that's the only way to know if we have an issue from the
subclassing that the compiler can't solve.  But where the wrapping leaked
into other SWCS like Chart and Graphics, I'm thinking of adding the
$displayObject variable in the Basic UIBase so we don't have to duplicate
the other SWCs as well.

-Alex

Re: AMFPHP support for FlexJS

[Carlos Rovira]

Hi Olaf, I think is more about efficiency and optimization. AMF is binary,
more compacted and faster that any other method I known out there. in terms
of usability is as well more easy to work with.

I'm afraid that AMF could not be successful as JSON maybe due to people not
know about the openness of the format and as well due to the way to work
with it through typed objects. One of its advantages and maybe a
disadventage since JSON is maybe more direct to work with (but very
cumbersome in the end).




2016-10-27 11:58 GMT+02:00 OK :

> There's a thread in the users list which might anser some your questions
> [1].
>
> From my perception REST with JSON is become some kind of de facto standard
> these days.
> Even if AMF is maybe technically the better choice, in times of API driven
> design it might be also important
> to provide reusable APIs that could be shared or consumed by anyone and
> anything.
>
> Creating a RESTful API is not so hard. In the PHP world one option to
> achive
> it with less effort is SLIM3 [2].
> Maybe you could "restify" yor current backend with reasonable effort.
>
> HTH,
> Olaf
>
> [1]
> http://apache-flex-users.246.n4.nabble.com/FlexJS-Support-in-BlazeDS-
> communication-td11562.html#a13951
>
> [2] http://www.slimframework.com/
>
>
>
> --
> View this message in context: http://apache-flex-
> development.247.n4.nabble.com/AMFPHP-support-for-FlexJS-
> tp56066p56069.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>



-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es


Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [FlexJS} When to Bead (was Re: [FlexJS] enabled property)

[Alex Harui]

On 10/27/16, 12:48 AM, "carlos.rov...@gmail.com on behalf of Carlos
Rovira"  wrote:

>Thanks,
>
>I was not thinking this from that point of view. Maybe in MDL has sense to
>include majority of beads since it's a concrete implementation of visuals:
>Material Design Lite
>But don't know if we could have a base control (ButtonBase...for example
>but doesn't like too much that name) and then another (the Button *actual
>class*) that instantiates ButtonEffect and Disable beads
>
>btw, if you notice, I remove the "Bead" ending in my beads, since I think
>is less verbose and the mxml is pretty descriptive (those are parte of
>js:beads).

It does look fine in MXML, but I worry about how to find them in ASDoc.
That's why I want to try to create a smarter doc app for FlexJS where we
mark classes with @bead and @component so folks can filter better.

>As well I implemented effects with boolean flags. I have to make different
>beads for different controls since are effect "per-control", with some to
>them common and available in an MDLEffect bead that the rest extend from.

IMO, it is all a trade-off.  The Basic set will have everything broken out
into beads, but I fully expect the most popular first-time-user component
set will have lots of beads aggregated into it to make developing your POC
less verbose.  So yes, you can break stuff out into pieces inside MDL as
well, but realize that is another trade-off.  An aggregation of beads will
be heavier and slower than just baking some code into the component, but
if you aggregate beads then you can factor them out later if you aren't
using.

-Alex

Re: CSSUtils.toColorWithAlpha

[Alex Harui]

On 10/27/16, 1:32 AM, "Harbs"  wrote:

>Alex, I think this question is for you since I think you wrote the code
>last July.
>
>The handling of rgba seems odd to me:
>
>else if ((c = stringValue.indexOf("rgba(")) != -1)
>{
>c2 = stringValue.indexOf(")");
>stringValue = stringValue.substring(c + 4, c2);
>var parts4:Array = stringValue.split(",");
>return (uint(parts4[3]) << 24 +
>uint(parts3[0]) << 16 +
>uint(parts3[1]) << 8 +
>uint(parts3[2]));
>}
>
>Besides a typo where parts3 is being used instead of parts4, there’s two
>issues I can see:
>1. The uint is being saved as ARGB rather than RGBA.
>2. RGB values are values between 0 and 255, while A values are between 0
>and 1.
>
>It does not look to me like this code ever worked. Any objection to me
>changing it to standardize on RGBA instead of ARGB?

Quite possible.  Doesn't have to stay that way for it to work in Flash?  I
started a separate thread about color handling.  Let's finish the
discussion there.

-Alex

Re: [FlexJS} When to Bead (was Re: [FlexJS] enabled property)

[Alex Harui]

On 10/27/16, 4:39 AM, "yishayw"  wrote:

>Regarding verboseness, maybe we could have a new css property such as
>'additionalBeads' which IStrand implementers look for and create?
>
>That keeps mxml compact with PAYG and flexibility.

Possible, but I'm not sure that is worth the instance initialization cost
at runtime.  IMO, if you want to bake in a set of additional beads, that
is when you subclass and add the beads.  MXMLComponents lends itself to
that pattern.

-Alex

Re: [FlexJS] DoubleClickEnabledBead ?

[Alex Harui]

On 10/26/16, 11:58 PM, "yishayw"  wrote:
>
>I was thinking that in general it could be nice to have an example of
>suppressing certain events in beads. The scenarios would be very similar
>to
>scenarios that require disabling all mouse events, which is what
>DisabledBead currently does. Sometimes there are a lot of event handlers
>on
>a single event and the simplest solution is to suppress the event rather
>than having all handlers check the target.
>

I think there may be more than one way to do this.  It may depend on what
you want to happen to any object behind the object under the mouse.  It is
one thing to suppress the event, and another to have it pass through to
the object behind.

What we end up doing may also depend on which event model we use which
depends on whether we wrap platform implementations or not.

If you don't need pass-through to objects behind, and aren't worried about
other beads on the strand listening for the event you want to block, I
think you can add a target listener in the strand setter and call
stopImmediatePropagation, and add a capture phase listener to the
topMostEventDispatcher.  Beads should have their strands set before most
other app-developer code starts to run.

There might be a better idea though.   I saw CSS pointer-events, but not
sure it works for non-SVG.

-Alex

Re: AW: [Website] gitpubsub working and NG-Website online

[Alex Harui]

Hi Chris,

Congratulations on becoming a member of Infra, and thanks for pushing this
effort forward.

-Alex

On 10/27/16, 12:22 AM, "Christofer Dutz"  wrote:

>Hi Harbs,
>
>
>well the news section is the same way on the current site. I don't think
>using a scrollable diff would be a good option. If you resize the website
>it adjusts to that and at a certain width it jumps to a one-column style.
>Having a scrollable div would make it hard for mobile users to navigate
>on the page.
>
>
>The title and the [] come from the carousel component ... it's the title
>and inside the [] usually the subtitle is contained. I would like to get
>rid of both as they sort of duplicate the content on the images. Will
>have to look into this.
>
>
>I will have to fine tune the "what is flex" page a little as this doesn't
>look good at the moment and the team page I have to find out how to force
>all images to be the same size and eventually have this "circle" effect
>the original had.
>
>
>Chris
>
>
>Von: Harbs 
>Gesendet: Donnerstag, 27. Oktober 2016 07:53:50
>An: dev@flex.apache.org
>Betreff: Re: [Website] gitpubsub working and NG-Website online
>
>Congratulations! Great news!
>
>I think the site is looking pretty good!
>
>Some small things I noticed:
>
>"Latest News” on the home page extends way beyond the other elements. I
>wonder if it should be inside a scrollable div or something.
>There’s extra “[]” characters in the bottom of the slider. Where are
>those coming from?
>
>On Oct 27, 2016, at 12:05 AM, Christofer Dutz 
>wrote:
>
>> Hi guys,
>>
>>
>> today I was made member of the infrastructure group and my first commit
>>was to activate gitpubsub to sync the asf-site branch I setup in the
>>flex-site git repo to "http://flex.apache.org/ng;. This was the missing
>>step on getting the new site online. There still need to be some things
>>fine-tuned and some pages adjusted, but now you can get an impression of
>>the new site without having to login, download, or build anything. So
>>please have a look at:
>>
>> http://flex.apache.org/ng/
>>
>> and tell me what you think.
>>
>>
>> Chris
>>
>>
>> PS: We definitely need to change the feather logo against the new one
>>;-)
>

[FLEXJS] Colors (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

[Alex Harui]

On 10/26/16, 11:59 PM, "Harbs"  wrote:

>There’s also an issue that Flash uses ARGB, while the default in browsers
>seems to be RGBA.
>
>I think simply avoiding uint representations of RGBA is the simplest
>solution…

Not quite sure what you mean by that.  Are you suggesting that we add an
RGB and RGBA class and use it instead of uint in our APIs?  I think that
might be worth a try.  It looks like there is an RGBColor class in JS.swc
already.  

Thoughts?
-Alex

Re: [FlexJS} When to Bead (was Re: [FlexJS] enabled property)

[yishayw]

yishayw wrote
> how do you re-enable a bead

should read


yishayw wrote
> how do you re-enable a strand





--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-When-to-Bead-was-Re-FlexJS-enabled-property-tp56044p56073.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS} When to Bead (was Re: [FlexJS] enabled property)

[yishayw]

Carlos, I had a look at Disable (I like the short name). 2 Questions: the swf
side isn't implemented, is that by design? Also, how do you re-enable a bead
that's been disabled? Thanks.



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-When-to-Bead-was-Re-FlexJS-enabled-property-tp56044p56072.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

AW: [Website] gitpubsub working and NG-Website online

[Christofer Dutz]

Ok ... so now the team page has equally sized circular pictures and the "what 
is flex" page is readable.


Chris


Von: Christofer Dutz 
Gesendet: Donnerstag, 27. Oktober 2016 09:22:08
An: dev@flex.apache.org
Betreff: AW: [Website] gitpubsub working and NG-Website online

Hi Harbs,


well the news section is the same way on the current site. I don't think using 
a scrollable diff would be a good option. If you resize the website it adjusts 
to that and at a certain width it jumps to a one-column style. Having a 
scrollable div would make it hard for mobile users to navigate on the page.


The title and the [] come from the carousel component ... it's the title and 
inside the [] usually the subtitle is contained. I would like to get rid of 
both as they sort of duplicate the content on the images. Will have to look 
into this.


I will have to fine tune the "what is flex" page a little as this doesn't look 
good at the moment and the team page I have to find out how to force all images 
to be the same size and eventually have this "circle" effect the original had.


Chris


Von: Harbs 
Gesendet: Donnerstag, 27. Oktober 2016 07:53:50
An: dev@flex.apache.org
Betreff: Re: [Website] gitpubsub working and NG-Website online

Congratulations! Great news!

I think the site is looking pretty good!

Some small things I noticed:

"Latest News” on the home page extends way beyond the other elements. I wonder 
if it should be inside a scrollable div or something.
There’s extra “[]” characters in the bottom of the slider. Where are those 
coming from?

On Oct 27, 2016, at 12:05 AM, Christofer Dutz  wrote:

> Hi guys,
>
>
> today I was made member of the infrastructure group and my first commit was 
> to activate gitpubsub to sync the asf-site branch I setup in the flex-site 
> git repo to "http://flex.apache.org/ng;. This was the missing step on getting 
> the new site online. There still need to be some things fine-tuned and some 
> pages adjusted, but now you can get an impression of the new site without 
> having to login, download, or build anything. So please have a look at:
>
> http://flex.apache.org/ng/
>
> and tell me what you think.
>
>
> Chris
>
>
> PS: We definitely need to change the feather logo against the new one ;-)

Re: [FlexJS} When to Bead (was Re: [FlexJS] enabled property)

[yishayw]

Regarding verboseness, maybe we could have a new css property such as
'additionalBeads' which IStrand implementers look for and create?

That keeps mxml compact with PAYG and flexibility. 



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-When-to-Bead-was-Re-FlexJS-enabled-property-tp56044p56070.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: AMFPHP support for FlexJS

[OK]

There's a thread in the users list which might anser some your questions [1].

>From my perception REST with JSON is become some kind of de facto standard
these days.
Even if AMF is maybe technically the better choice, in times of API driven
design it might be also important 
to provide reusable APIs that could be shared or consumed by anyone and
anything.

Creating a RESTful API is not so hard. In the PHP world one option to achive
it with less effort is SLIM3 [2].
Maybe you could "restify" yor current backend with reasonable effort.

HTH,
Olaf

[1]
http://apache-flex-users.246.n4.nabble.com/FlexJS-Support-in-BlazeDS-communication-td11562.html#a13951

[2] http://www.slimframework.com/



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/AMFPHP-support-for-FlexJS-tp56066p56069.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: AMFPHP support for FlexJS

[Carlos Rovira]

Hi Fréderic,

thanks for joining :)

AMF is currently not supported, but it was discussed several times in the
list.
Many of us agree that AMF is currently the best communication protocol out
there (I even don't understand the JSON success taking into account AMF is
open source specification and was implemented in almost every language out
there, but hey! world turned from Flash to HTML so I expect anything ;P).

In JS there's some basic protocol ports out there, but we need an high
level library that brings to FlexJS what old Flex SDK has with rpc.swc. We
basically need the *RemoteObject* implementation that eases the use of AMF
in JS as you posted.

As you, many of us would need this communication layer to avoid change any
server side code if we want support a FlexJS front end layer to our
applications.

Nobody is currently working on this, But Chris Dutz talked about contribute
to this. Chris is contributing with building tooling, maven, site, and
maybe you could talk with him in order to start looking at how to bring AMF
to FlexJS. Your help would be so much appreciated.

Without doubt for me is one of the key pieces that we need.

Thanks!



2016-10-27 10:56 GMT+02:00 Fréderic Cox :

> Hi,
>
> I have been following this list for quite a while now.
> Thanks to Carlos his MDL efforts and post on Twitter I am considering to
> start working with FlexJS in the coming days.
>
> I am reading the FAQ's and hope to get everything set-up soon but there is
> one big feature I used a lot in all my projects and that is AMFPHP via the
> RemoteObject class.
>
> Is AMFPHP technically possible with FlexJS? Our entire backend supports
> AMFPHP so I would prefer not to change all of that to JSON.
>
> AS3 code is like this:
>
> var dataService:RemoteObject = new RemoteObject;
>
> dataService.destination = "Crm";
>
> dataService.source = "Crm";
>
> dataService.endpoint = EnalityData.rootURL + "amfphp/gateway.php";
>
> dataService.addEventListener(ResultEvent.RESULT,
> companiesDataResultHandler, false, 0, true);
>
> dataService.addEventListener(FaultEvent.FAULT, companiesDataFaultHandler,
> false, 0, true);
>
> dataService.getOperation("getCompaniesInfo").arguments=[
> EnalityData.userLogin,
> EnalityData.userPassword, EnalityData.userId];
>
> dataService.getOperation("getCompaniesInfo").send();
>
>
> AMFPHP is superfast and easy to use. It would allow me to convert some, if
> not all, of my applications to FlexJS. I'm a DIY programmer with 10+ year
> of experience but never studied actual advanced programming studies (more
> Communication & Multimedia). Been working with AS3 for over 10 years now.
> Some concepts here are still over my head but I'm willing to learn it.
>
> So basically my questions regarding AMFPHP for FlexJS are:
>
> 1) Is AMFPHP currently supported for FlexJS
>
> 2) If not supported, is it technically possible?
>
> 3) If not supported but technically possible, is anyone already working on
> it?
>
> 4) If nobody is working on it, who has the experience/tips on how to get
> this working for FlexJS?
>



-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es


Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

[Carlos Rovira]

Ok,

As a base thinking, and taking into account I didn't gave the cycles you
all invested in it, I should notice that FlexJS is not Flash anymore. Is
something that could output various things. One of them are SWF, and other
is HTML, but we could output more some day. Maybe even FlexJS is not an
accurate name for the future, since right not our priority in HTML (and SWF
but not as important as the first), but maybe in 5 years we could think in
other important output by that time.
So, I think make sense to make FlexJS not subclassing Flash Objects in
particular, but more than that, I should see some of the code to understand
the approach.

thanks

Carlos



2016-10-27 10:11 GMT+02:00 Harbs :

> Hi Carlos,
>
> The refactor was already done, and I’ve been working off the
> sprite-refactor branch for a few months already. I’ve been regularly
> merging the changes from develop into that branch. There is however, a lot
> of work done on the sprite-refactor branch which has not made it into
> develop.
>
> The reason for the refactor was because I ran into lots of issues related
> to the fact that FlexJS components are subclassing Flash objects rather
> than wrapping them. How many of these issues can be resolved by tooling
> remain to be seen.
>
> All the samples currently run on both branches, and the impact to client
> code will hopefully be minimal (if impacted at all).
>
> I will do what I can to merge your MDL branch into the refactored code if
> there are conflicts. I doubt there will be any though.
>
> Alex and I will probably be doing most of the flipping between the two
> options until we settle on a permanent strategy for the two approaches.
>
> HTH,
> Harbs
>
> On Oct 27, 2016, at 10:56 AM, Carlos Rovira 
> wrote:
>
> > Hi,
> >
> > don't know how you plan to do this, but seems an important refactor and
> > lots of files included.
> > I suggest to do this in an "integration" branch to manage all posible
> > colateral issues generated. And then as adjusted merge with develop.
> >
> > As well, I came to the discussion too much late so I don't know about the
> > basic thinking of this refactor. Could you share what's behind? (now that
> > you discuss it for long time)
> >
> > Thanks
> >
> >
> >
> > 2016-10-27 9:17 GMT+02:00 Harbs :
> >
> >> There’s also differences related to events and the like, but we can add
> >> blocks for that as well.
> >>
> >> On Oct 27, 2016, at 10:15 AM, Harbs  wrote:
> >>
> >>> I had an idea last night:
> >>>
> >>> Instead of having two different namespaces for wrapped and unwrapped
> >> components, what about making it a compiler option?
> >>>
> >>> The primary difference between the two is:
> >>> 1. The base class is different.
> >>> 2. References in platform-specific code to the platform-specific
> >> implementation when needed.
> >>>
> >>> #1 can be resolved by conditional compilation blocks (such as
> >> COMPILE::OPTIMIZE_PERFORMANCE and COMPILE::OPTIMIZE_COMPATIBILITY)
> >>> #2 can be resolved by having a variable which points to the
> >> implementation (and typed as an Object) So for wrapped components,
> >> myComponents.impl (or whatever we’d call it) would be
> HTMLElementWrapper.$displayObject
> >> and for subclassed components it would be “this”. For HTML, it would be
> >> element, etc.
> >>>
> >>> Thoughts?
> >>>
> >>> On Oct 27, 2016, at 9:57 AM, Alex Harui  wrote:
> >>>
>  I've been looking at the differences between develop and
> refactor-sprite
>  and how to manage the fork of the Basic set into both a wrapped and
>  unwrapped set.
> 
>  I found that I can just copy the HTML folder to a Basic folder and you
> >> can
>  use --follow on the copies to follow history in the fork.
> 
>  In looking at the examples, they often import org.apache.flex.html.*,
> so
>  I'm tempted to not rename the packaging in the Basic folder so it is
>  easier to switch from wrapped to unwrapped.  It appears that the
> >> compiler
>  doesn't care that both Basic.swc and HTML.swc have the same classes.
>  Because the HTML.swc is compiled later, it has a newer timestamp and
> its
>  classes are used by default in IDE and Ant builds.  I think for Maven
> >> you
>  just specify one or the other in the pom.xml.  I think that should be
> ok
>  since I'll be the primary person switching between the two and I can
>  control which classes I am using.
> 
>  I think the next move is to move-and-fork many classes from Core to
> both
>  Basic and HTML so each folder can have its own fork of UIBase,
>  Application, View, etc.
> 
>  This should leave org.apache.flex.core with mostly interfaces.  Which
> is
>  probably a good thing.  There might need to be some move-and-forking
> >> for a
>  few org.apache.flex.utils.
> 
>  I think I do these steps in develop, then merge them into
> 

AMFPHP support for FlexJS

[Fréderic Cox]

Hi,

I have been following this list for quite a while now.
Thanks to Carlos his MDL efforts and post on Twitter I am considering to
start working with FlexJS in the coming days.

I am reading the FAQ's and hope to get everything set-up soon but there is
one big feature I used a lot in all my projects and that is AMFPHP via the
RemoteObject class.

Is AMFPHP technically possible with FlexJS? Our entire backend supports
AMFPHP so I would prefer not to change all of that to JSON.

AS3 code is like this:

var dataService:RemoteObject = new RemoteObject;

dataService.destination = "Crm";

dataService.source = "Crm";

dataService.endpoint = EnalityData.rootURL + "amfphp/gateway.php";

dataService.addEventListener(ResultEvent.RESULT,
companiesDataResultHandler, false, 0, true);

dataService.addEventListener(FaultEvent.FAULT, companiesDataFaultHandler,
false, 0, true);

dataService.getOperation("getCompaniesInfo").arguments=[EnalityData.userLogin,
EnalityData.userPassword, EnalityData.userId];

dataService.getOperation("getCompaniesInfo").send();


AMFPHP is superfast and easy to use. It would allow me to convert some, if
not all, of my applications to FlexJS. I'm a DIY programmer with 10+ year
of experience but never studied actual advanced programming studies (more
Communication & Multimedia). Been working with AS3 for over 10 years now.
Some concepts here are still over my head but I'm willing to learn it.

So basically my questions regarding AMFPHP for FlexJS are:

1) Is AMFPHP currently supported for FlexJS

2) If not supported, is it technically possible?

3) If not supported but technically possible, is anyone already working on
it?

4) If nobody is working on it, who has the experience/tips on how to get
this working for FlexJS?

CSSUtils.toColorWithAlpha

[Harbs]

Alex, I think this question is for you since I think you wrote the code last 
July.

The handling of rgba seems odd to me:

else if ((c = stringValue.indexOf("rgba(")) != -1)
{
c2 = stringValue.indexOf(")");
stringValue = stringValue.substring(c + 4, c2);
var parts4:Array = stringValue.split(",");
return (uint(parts4[3]) << 24 + 
uint(parts3[0]) << 16 +
uint(parts3[1]) << 8 +
uint(parts3[2]));
}

Besides a typo where parts3 is being used instead of parts4, there’s two issues 
I can see:
1. The uint is being saved as ARGB rather than RGBA.
2. RGB values are values between 0 and 255, while A values are between 0 and 1.

It does not look to me like this code ever worked. Any objection to me changing 
it to standardize on RGBA instead of ARGB?

Thanks,
Harbs

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

[Harbs]

Hi Carlos,

The refactor was already done, and I’ve been working off the sprite-refactor 
branch for a few months already. I’ve been regularly merging the changes from 
develop into that branch. There is however, a lot of work done on the 
sprite-refactor branch which has not made it into develop.

The reason for the refactor was because I ran into lots of issues related to 
the fact that FlexJS components are subclassing Flash objects rather than 
wrapping them. How many of these issues can be resolved by tooling remain to be 
seen.

All the samples currently run on both branches, and the impact to client code 
will hopefully be minimal (if impacted at all).

I will do what I can to merge your MDL branch into the refactored code if there 
are conflicts. I doubt there will be any though.

Alex and I will probably be doing most of the flipping between the two options 
until we settle on a permanent strategy for the two approaches.

HTH,
Harbs

On Oct 27, 2016, at 10:56 AM, Carlos Rovira  
wrote:

> Hi,
> 
> don't know how you plan to do this, but seems an important refactor and
> lots of files included.
> I suggest to do this in an "integration" branch to manage all posible
> colateral issues generated. And then as adjusted merge with develop.
> 
> As well, I came to the discussion too much late so I don't know about the
> basic thinking of this refactor. Could you share what's behind? (now that
> you discuss it for long time)
> 
> Thanks
> 
> 
> 
> 2016-10-27 9:17 GMT+02:00 Harbs :
> 
>> There’s also differences related to events and the like, but we can add
>> blocks for that as well.
>> 
>> On Oct 27, 2016, at 10:15 AM, Harbs  wrote:
>> 
>>> I had an idea last night:
>>> 
>>> Instead of having two different namespaces for wrapped and unwrapped
>> components, what about making it a compiler option?
>>> 
>>> The primary difference between the two is:
>>> 1. The base class is different.
>>> 2. References in platform-specific code to the platform-specific
>> implementation when needed.
>>> 
>>> #1 can be resolved by conditional compilation blocks (such as
>> COMPILE::OPTIMIZE_PERFORMANCE and COMPILE::OPTIMIZE_COMPATIBILITY)
>>> #2 can be resolved by having a variable which points to the
>> implementation (and typed as an Object) So for wrapped components,
>> myComponents.impl (or whatever we’d call it) would be 
>> HTMLElementWrapper.$displayObject
>> and for subclassed components it would be “this”. For HTML, it would be
>> element, etc.
>>> 
>>> Thoughts?
>>> 
>>> On Oct 27, 2016, at 9:57 AM, Alex Harui  wrote:
>>> 
 I've been looking at the differences between develop and refactor-sprite
 and how to manage the fork of the Basic set into both a wrapped and
 unwrapped set.
 
 I found that I can just copy the HTML folder to a Basic folder and you
>> can
 use --follow on the copies to follow history in the fork.
 
 In looking at the examples, they often import org.apache.flex.html.*, so
 I'm tempted to not rename the packaging in the Basic folder so it is
 easier to switch from wrapped to unwrapped.  It appears that the
>> compiler
 doesn't care that both Basic.swc and HTML.swc have the same classes.
 Because the HTML.swc is compiled later, it has a newer timestamp and its
 classes are used by default in IDE and Ant builds.  I think for Maven
>> you
 just specify one or the other in the pom.xml.  I think that should be ok
 since I'll be the primary person switching between the two and I can
 control which classes I am using.
 
 I think the next move is to move-and-fork many classes from Core to both
 Basic and HTML so each folder can have its own fork of UIBase,
 Application, View, etc.
 
 This should leave org.apache.flex.core with mostly interfaces.  Which is
 probably a good thing.  There might need to be some move-and-forking
>> for a
 few org.apache.flex.utils.
 
 I think I do these steps in develop, then merge them into
>> refactor-sprite,
 then try to merge refactor-sprite into develop.
 
 Anybody have a better plan or see big holes in this one?  I'm done for
 tonight and will check in the AM.
 
 Thanks,
 -Alex
 
>>> 
>> 
>> 
> 
> 
> -- 
> 
> Carlos Rovira
> Director General
> M: +34 607 22 60 05
> http://www.codeoscopic.com
> http://www.avant2.es
> 
> 
> Este mensaje se dirige exclusivamente a su destinatario y puede contener
> información privilegiada o confidencial. Si ha recibido este mensaje por
> error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
> proceda a su destrucción.
> 
> De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
> que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
> S.A. La finalidad de dicho tratamiento es facilitar la prestación del
> servicio o información solicitados, teniendo 

Re: MDL Tweet

[OK]

Great progress Carlos, thanks to make it happen!!!

Olaf



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/MDL-Tweet-tp56042p56064.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

[Carlos Rovira]

Hi,

don't know how you plan to do this, but seems an important refactor and
lots of files included.
I suggest to do this in an "integration" branch to manage all posible
colateral issues generated. And then as adjusted merge with develop.

As well, I came to the discussion too much late so I don't know about the
basic thinking of this refactor. Could you share what's behind? (now that
you discuss it for long time)

Thanks



2016-10-27 9:17 GMT+02:00 Harbs :

> There’s also differences related to events and the like, but we can add
> blocks for that as well.
>
> On Oct 27, 2016, at 10:15 AM, Harbs  wrote:
>
> > I had an idea last night:
> >
> > Instead of having two different namespaces for wrapped and unwrapped
> components, what about making it a compiler option?
> >
> > The primary difference between the two is:
> > 1. The base class is different.
> > 2. References in platform-specific code to the platform-specific
> implementation when needed.
> >
> > #1 can be resolved by conditional compilation blocks (such as
> COMPILE::OPTIMIZE_PERFORMANCE and COMPILE::OPTIMIZE_COMPATIBILITY)
> > #2 can be resolved by having a variable which points to the
> implementation (and typed as an Object) So for wrapped components,
> myComponents.impl (or whatever we’d call it) would be 
> HTMLElementWrapper.$displayObject
> and for subclassed components it would be “this”. For HTML, it would be
> element, etc.
> >
> > Thoughts?
> >
> > On Oct 27, 2016, at 9:57 AM, Alex Harui  wrote:
> >
> >> I've been looking at the differences between develop and refactor-sprite
> >> and how to manage the fork of the Basic set into both a wrapped and
> >> unwrapped set.
> >>
> >> I found that I can just copy the HTML folder to a Basic folder and you
> can
> >> use --follow on the copies to follow history in the fork.
> >>
> >> In looking at the examples, they often import org.apache.flex.html.*, so
> >> I'm tempted to not rename the packaging in the Basic folder so it is
> >> easier to switch from wrapped to unwrapped.  It appears that the
> compiler
> >> doesn't care that both Basic.swc and HTML.swc have the same classes.
> >> Because the HTML.swc is compiled later, it has a newer timestamp and its
> >> classes are used by default in IDE and Ant builds.  I think for Maven
> you
> >> just specify one or the other in the pom.xml.  I think that should be ok
> >> since I'll be the primary person switching between the two and I can
> >> control which classes I am using.
> >>
> >> I think the next move is to move-and-fork many classes from Core to both
> >> Basic and HTML so each folder can have its own fork of UIBase,
> >> Application, View, etc.
> >>
> >> This should leave org.apache.flex.core with mostly interfaces.  Which is
> >> probably a good thing.  There might need to be some move-and-forking
> for a
> >> few org.apache.flex.utils.
> >>
> >> I think I do these steps in develop, then merge them into
> refactor-sprite,
> >> then try to merge refactor-sprite into develop.
> >>
> >> Anybody have a better plan or see big holes in this one?  I'm done for
> >> tonight and will check in the AM.
> >>
> >> Thanks,
> >> -Alex
> >>
> >
>
>


-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es


Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [FlexJS} When to Bead (was Re: [FlexJS] enabled property)

[Carlos Rovira]

Thanks,

I was not thinking this from that point of view. Maybe in MDL has sense to
include majority of beads since it's a concrete implementation of visuals:
Material Design Lite
But don't know if we could have a base control (ButtonBase...for example
but doesn't like too much that name) and then another (the Button *actual
class*) that instantiates ButtonEffect and Disable beads

btw, if you notice, I remove the "Bead" ending in my beads, since I think
is less verbose and the mxml is pretty descriptive (those are parte of
js:beads).
As well I implemented effects with boolean flags. I have to make different
beads for different controls since are effect "per-control", with some to
them common and available in an MDLEffect bead that the rest extend from.



2016-10-27 8:26 GMT+02:00 yishayw :

> Another advantage of beads, as I see it, is that they can be modular. The
> way
> I implemented DisableBead it does the minimum, which is to change
> style.pointerEvents to 'none', but it also dispatches a 'disabledChange'
> event on the strand. The latter allows an additional bead, e.g. BlurBead,
> to
> listen to 'disabledChanged' and change opacity. Then you get the default
> behavior, which is to disable pointer events, and an added effect where
> necessary, reusing code.
>
> To minimize verboseness I suppose you could have 'DisableAndBlurBead' which
> adds 'DisableBead' and 'BlurBead'. Of course, baking it in in advance is
> the
> least verbose and could work for a non-basic component set.
>
>
>
>
> --
> View this message in context: http://apache-flex-
> development.247.n4.nabble.com/FlexJS-When-to-Bead-was-
> Re-FlexJS-enabled-property-tp56044p56049.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>



-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es


Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: MDL Tweet

[Carlos Rovira]

Thanks Om! :)

2016-10-27 0:30 GMT+02:00 OmPrakash Muppirala :

> Done!
>
> On Wed, Oct 26, 2016 at 2:29 PM, Carlos Rovira 
> wrote:
>
> > Please, retweet to make some noise out there! :)
> >
> > https://twitter.com/carlosrovira/status/791379921746690049
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>



-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es


Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

AW: [Website] gitpubsub working and NG-Website online

[Christofer Dutz]

Hi Harbs,


well the news section is the same way on the current site. I don't think using 
a scrollable diff would be a good option. If you resize the website it adjusts 
to that and at a certain width it jumps to a one-column style. Having a 
scrollable div would make it hard for mobile users to navigate on the page.


The title and the [] come from the carousel component ... it's the title and 
inside the [] usually the subtitle is contained. I would like to get rid of 
both as they sort of duplicate the content on the images. Will have to look 
into this.


I will have to fine tune the "what is flex" page a little as this doesn't look 
good at the moment and the team page I have to find out how to force all images 
to be the same size and eventually have this "circle" effect the original had.


Chris


Von: Harbs 
Gesendet: Donnerstag, 27. Oktober 2016 07:53:50
An: dev@flex.apache.org
Betreff: Re: [Website] gitpubsub working and NG-Website online

Congratulations! Great news!

I think the site is looking pretty good!

Some small things I noticed:

"Latest News” on the home page extends way beyond the other elements. I wonder 
if it should be inside a scrollable div or something.
There’s extra “[]” characters in the bottom of the slider. Where are those 
coming from?

On Oct 27, 2016, at 12:05 AM, Christofer Dutz  wrote:

> Hi guys,
>
>
> today I was made member of the infrastructure group and my first commit was 
> to activate gitpubsub to sync the asf-site branch I setup in the flex-site 
> git repo to "http://flex.apache.org/ng;. This was the missing step on getting 
> the new site online. There still need to be some things fine-tuned and some 
> pages adjusted, but now you can get an impression of the new site without 
> having to login, download, or build anything. So please have a look at:
>
> http://flex.apache.org/ng/
>
> and tell me what you think.
>
>
> Chris
>
>
> PS: We definitely need to change the feather logo against the new one ;-)

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

[Harbs]

There’s also differences related to events and the like, but we can add blocks 
for that as well.

On Oct 27, 2016, at 10:15 AM, Harbs  wrote:

> I had an idea last night:
> 
> Instead of having two different namespaces for wrapped and unwrapped 
> components, what about making it a compiler option?
> 
> The primary difference between the two is:
> 1. The base class is different.
> 2. References in platform-specific code to the platform-specific 
> implementation when needed.
> 
> #1 can be resolved by conditional compilation blocks (such as 
> COMPILE::OPTIMIZE_PERFORMANCE and COMPILE::OPTIMIZE_COMPATIBILITY)
> #2 can be resolved by having a variable which points to the implementation 
> (and typed as an Object) So for wrapped components, myComponents.impl (or 
> whatever we’d call it) would be HTMLElementWrapper.$displayObject and for 
> subclassed components it would be “this”. For HTML, it would be element, etc.
> 
> Thoughts?
> 
> On Oct 27, 2016, at 9:57 AM, Alex Harui  wrote:
> 
>> I've been looking at the differences between develop and refactor-sprite
>> and how to manage the fork of the Basic set into both a wrapped and
>> unwrapped set.
>> 
>> I found that I can just copy the HTML folder to a Basic folder and you can
>> use --follow on the copies to follow history in the fork.
>> 
>> In looking at the examples, they often import org.apache.flex.html.*, so
>> I'm tempted to not rename the packaging in the Basic folder so it is
>> easier to switch from wrapped to unwrapped.  It appears that the compiler
>> doesn't care that both Basic.swc and HTML.swc have the same classes.
>> Because the HTML.swc is compiled later, it has a newer timestamp and its
>> classes are used by default in IDE and Ant builds.  I think for Maven you
>> just specify one or the other in the pom.xml.  I think that should be ok
>> since I'll be the primary person switching between the two and I can
>> control which classes I am using.
>> 
>> I think the next move is to move-and-fork many classes from Core to both
>> Basic and HTML so each folder can have its own fork of UIBase,
>> Application, View, etc.
>> 
>> This should leave org.apache.flex.core with mostly interfaces.  Which is
>> probably a good thing.  There might need to be some move-and-forking for a
>> few org.apache.flex.utils.
>> 
>> I think I do these steps in develop, then merge them into refactor-sprite,
>> then try to merge refactor-sprite into develop.
>> 
>> Anybody have a better plan or see big holes in this one?  I'm done for
>> tonight and will check in the AM.
>> 
>> Thanks,
>> -Alex
>> 
> 

Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

[Harbs]

I had an idea last night:

Instead of having two different namespaces for wrapped and unwrapped 
components, what about making it a compiler option?

The primary difference between the two is:
1. The base class is different.
2. References in platform-specific code to the platform-specific implementation 
when needed.

#1 can be resolved by conditional compilation blocks (such as 
COMPILE::OPTIMIZE_PERFORMANCE and COMPILE::OPTIMIZE_COMPATIBILITY)
#2 can be resolved by having a variable which points to the implementation (and 
typed as an Object) So for wrapped components, myComponents.impl (or whatever 
we’d call it) would be HTMLElementWrapper.$displayObject and for subclassed 
components it would be “this”. For HTML, it would be element, etc.

Thoughts?

On Oct 27, 2016, at 9:57 AM, Alex Harui  wrote:

> I've been looking at the differences between develop and refactor-sprite
> and how to manage the fork of the Basic set into both a wrapped and
> unwrapped set.
> 
> I found that I can just copy the HTML folder to a Basic folder and you can
> use --follow on the copies to follow history in the fork.
> 
> In looking at the examples, they often import org.apache.flex.html.*, so
> I'm tempted to not rename the packaging in the Basic folder so it is
> easier to switch from wrapped to unwrapped.  It appears that the compiler
> doesn't care that both Basic.swc and HTML.swc have the same classes.
> Because the HTML.swc is compiled later, it has a newer timestamp and its
> classes are used by default in IDE and Ant builds.  I think for Maven you
> just specify one or the other in the pom.xml.  I think that should be ok
> since I'll be the primary person switching between the two and I can
> control which classes I am using.
> 
> I think the next move is to move-and-fork many classes from Core to both
> Basic and HTML so each folder can have its own fork of UIBase,
> Application, View, etc.
> 
> This should leave org.apache.flex.core with mostly interfaces.  Which is
> probably a good thing.  There might need to be some move-and-forking for a
> few org.apache.flex.utils.
> 
> I think I do these steps in develop, then merge them into refactor-sprite,
> then try to merge refactor-sprite into develop.
> 
> Anybody have a better plan or see big holes in this one?  I'm done for
> tonight and will check in the AM.
> 
> Thanks,
> -Alex
> 

Re: [FlexJS] DoubleClickEnabledBead ?

[yishayw]

Alex Harui wrote
> On 10/26/16, 11:07 PM, "yishayw" 

> yishayjobs@

>  wrote:
> 
>>In flash doubleClick events are not dispatched unless
>>InterActiveObject.doubleClickEnabled is set to true. In HTML there's no
>>such
>>property and dblclick is always dispatched. We'd like add
>>doubleClickEnabled
>>to FlexJS and were thinking of doing it in a bead.
>>
>>The question is how to implement it on the JS side. One idea is to add an
>>event handler to dblclick with max priority and decide whether or not to
>>stop event propagation. The problem is I don't see a way to add priorities
>>to event handlers.
>>
>>Any ideas?
> 
> IMO, it depends a bit on your goals.  There are already some SWF-centric
> beads.  In fact, the simplest DisableBead mainly saves code in a SWF for
> instances that don't need disabled behavior.  On the JS side, I think it
> just flips the HTMLElement's disabled property.  But enable/disable is
> also in a bead in order to allow for different visual effects.
> 
> 
> Will all apps need double click events?  Or maybe 80% of apps?  Or is your
> goal to suppress dblclick in certain scenarios on the JS side?  If the
> goal is to suppress, what kind of scenarios require that?
> 
> One option is just to have UIBase set InterActiveObject.doubleClickEnabled
> to true in the constructor so each UIBase has the same behavior on both
> SWF and JS.  I'm not sure what the costs are of turning that flag on on
> the SWF side.  Or does Flash eat the second click event?
> 
> -Alex

I already added doubleClickEnabled=true to UIBase, which seems in line with
making FlexJS' behavior HTML like.

In our app, we turn doubleClickEnabled for components on and off depending
on whether or not they're editable. We could get around it by checking the
target in the event handler.

I was thinking that in general it could be nice to have an example of
suppressing certain events in beads. The scenarios would be very similar to
scenarios that require disabling all mouse events, which is what
DisabledBead currently does. Sometimes there are a lot of event handlers on
a single event and the simplest solution is to suppress the event rather
than having all handlers check the target.



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

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Alex Harui]

On 10/26/16, 11:51 PM, "Harbs"  wrote:

>I don’t need it now that we changed our code. I added the check because I
>thought other might be bitten by the same issue.
>
>If we remove the check, I’m not going to add another class.

I do envision "debug-mode" beads and classes that do parameter/value
validation, since that will speed up development, but I hope to find a way
to easily swap those out for production beads that don't do
parameter/value validation.

It's ok to leave the checks in for now, but hopefully some day there will
be a way to opt-in/out such code.

Thanks,
-Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Harbs]

There’s also an issue that Flash uses ARGB, while the default in browsers seems 
to be RGBA.

I think simply avoiding uint representations of RGBA is the simplest solution…

On Oct 27, 2016, at 9:43 AM, Alex Harui  wrote:

>> This code works in Flash because it supports argb. I took the easy way
>> out by simply rejecting argb values, but I guess we could break off the
>> alpha channel and set the alpha with that value.
> 
> That sound like there are multiple possible solutions so there should be
> multiple classes, one for each solution.  IIRC, CSS has RGB and RGBA types
> and we may need to support both properly.
> 
> Maybe we need to find a way to introduce an RGB and RGBA type in an
> efficient way so you can strongly type your color handling code. IMO it is
> a bit of a hack to be using uint for a Color, but that's how Flash does it.

Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)

[Alex Harui]

I've been looking at the differences between develop and refactor-sprite
and how to manage the fork of the Basic set into both a wrapped and
unwrapped set.

I found that I can just copy the HTML folder to a Basic folder and you can
use --follow on the copies to follow history in the fork.

In looking at the examples, they often import org.apache.flex.html.*, so
I'm tempted to not rename the packaging in the Basic folder so it is
easier to switch from wrapped to unwrapped.  It appears that the compiler
doesn't care that both Basic.swc and HTML.swc have the same classes.
Because the HTML.swc is compiled later, it has a newer timestamp and its
classes are used by default in IDE and Ant builds.  I think for Maven you
just specify one or the other in the pom.xml.  I think that should be ok
since I'll be the primary person switching between the two and I can
control which classes I am using.

I think the next move is to move-and-fork many classes from Core to both
Basic and HTML so each folder can have its own fork of UIBase,
Application, View, etc.

This should leave org.apache.flex.core with mostly interfaces.  Which is
probably a good thing.  There might need to be some move-and-forking for a
few org.apache.flex.utils.

I think I do these steps in develop, then merge them into refactor-sprite,
then try to merge refactor-sprite into develop.

Anybody have a better plan or see big holes in this one?  I'm done for
tonight and will check in the AM.

Thanks,
-Alex

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Harbs]

I don’t need it now that we changed our code. I added the check because I 
thought other might be bitten by the same issue.

If we remove the check, I’m not going to add another class.

On Oct 27, 2016, at 9:43 AM, Alex Harui  wrote:

> 
> Every bit of code costs in CPU and download size.  It all adds up
> gradually.  And I'd bet there are a significant number of applications
> that don't need these checks in production.  You are welcome to create
> ValidatingSolidColor if you really need it.

Re: [FlexJS] HTMLElementWrapper extending Sprite

[Alex Harui]

On 10/26/16, 10:41 PM, "Harbs"  wrote:

>Sure, components should try and validate their values, but client code is
>not necessarily components, and it’s pretty easy to introduce a bug where
>client code supplies a wrong value.

IMO, if you are using typed ValueObjects you should do some validation
when storing any value, not just colors, in the ValueObjects.

>
>I do a lot of loading of content programmatically. This includes things
>like colors. The dynamic content does not cleanly fit into MXML and pure
>components. Setting properties using client code is the norm.
>
>Are worried about the performance implications of an extra check?

Every bit of code costs in CPU and download size.  It all adds up
gradually.  And I'd bet there are a significant number of applications
that don't need these checks in production.  You are welcome to create
ValidatingSolidColor if you really need it.

>
>In our case we had some code like this in our app:
>
>   var fill:SolidColor = new SolidColor(0x, 1);
>   var stroke:SolidColorStroke = new 
> SolidColorStroke(0x,1, 1);
>
>The color value could just as easily have been a variable whose value is
>determined at runtime.
>
>This code works in Flash because it supports argb. I took the easy way
>out by simply rejecting argb values, but I guess we could break off the
>alpha channel and set the alpha with that value.

That sound like there are multiple possible solutions so there should be
multiple classes, one for each solution.  IIRC, CSS has RGB and RGBA types
and we may need to support both properly.

Maybe we need to find a way to introduce an RGB and RGBA type in an
efficient way so you can strongly type your color handling code. IMO it is
a bit of a hack to be using uint for a Color, but that's how Flash does it.

-Alex

Re: [FlexJS] DoubleClickEnabledBead ?

[Alex Harui]

On 10/26/16, 11:07 PM, "yishayw"  wrote:

>In flash doubleClick events are not dispatched unless
>InterActiveObject.doubleClickEnabled is set to true. In HTML there's no
>such
>property and dblclick is always dispatched. We'd like add
>doubleClickEnabled
>to FlexJS and were thinking of doing it in a bead.
>
>The question is how to implement it on the JS side. One idea is to add an
>event handler to dblclick with max priority and decide whether or not to
>stop event propagation. The problem is I don't see a way to add priorities
>to event handlers.
>
>Any ideas?

IMO, it depends a bit on your goals.  There are already some SWF-centric
beads.  In fact, the simplest DisableBead mainly saves code in a SWF for
instances that don't need disabled behavior.  On the JS side, I think it
just flips the HTMLElement's disabled property.  But enable/disable is
also in a bead in order to allow for different visual effects.


Will all apps need double click events?  Or maybe 80% of apps?  Or is your
goal to suppress dblclick in certain scenarios on the JS side?  If the
goal is to suppress, what kind of scenarios require that?

One option is just to have UIBase set InterActiveObject.doubleClickEnabled
to true in the constructor so each UIBase has the same behavior on both
SWF and JS.  I'm not sure what the costs are of turning that flag on on
the SWF side.  Or does Flash eat the second click event?

-Alex

Re: [FlexJS} When to Bead (was Re: [FlexJS] enabled property)

[yishayw]

Another advantage of beads, as I see it, is that they can be modular. The way
I implemented DisableBead it does the minimum, which is to change
style.pointerEvents to 'none', but it also dispatches a 'disabledChange'
event on the strand. The latter allows an additional bead, e.g. BlurBead, to
listen to 'disabledChanged' and change opacity. Then you get the default
behavior, which is to disable pointer events, and an added effect where
necessary, reusing code.

To minimize verboseness I suppose you could have 'DisableAndBlurBead' which
adds 'DisableBead' and 'BlurBead'. Of course, baking it in in advance is the
least verbose and could work for a non-basic component set.




--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-When-to-Bead-was-Re-FlexJS-enabled-property-tp56044p56049.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

[FlexJS] DoubleClickEnabledBead ?

[yishayw]

In flash doubleClick events are not dispatched unless
InterActiveObject.doubleClickEnabled is set to true. In HTML there's no such
property and dblclick is always dispatched. We'd like add doubleClickEnabled
to FlexJS and were thinking of doing it in a bead. 

The question is how to implement it on the JS side. One idea is to add an
event handler to dblclick with max priority and decide whether or not to
stop event propagation. The problem is I don't see a way to add priorities
to event handlers. 

Any ideas?



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