Re: [FlexJS][SpriteFlexJS] DEFINES not in SpriteJS

[Alex Harui]

On 2/21/17, 11:40 AM, "Josh Tynjala"  wrote:

>COMPILE::JS and COMPILE:SWC are just regular compile-time constants. As
>far
>as I know, they receive no special treatment from the compiler. It's just
>a
>convention used by the FlexJS framework projects to make the components
>exclude certain code on some platforms. If you're targeting one platform,
>there shouldn't be any need to exclude anything, so this project shouldn't
>need COMPILE::JS at all.
>
>Why do you feel that COMPILE::JS is needed?

I think because Maven automatically plugs in playerglobal or airglobal for
the SWF build of a SWC.  I think Maven has some skip options that can go
in the POM?

-Alex

Re: [FlexJS]Layout redux

[Alex Harui]

It is probably time for our annual "revisiting of the layout code".  I
think if you look at source code history, Peter or I do this every so
often as we get more examples to work with.

From memory, there are issues like whether we have to set
position:relative or not that came out of the MDL swc.  And when/if we
need to set the width on a parent for percentage width to work in the
children/grandchildren.

It is great to finally have some people actually paying attention that
know how this stuff is actually normally done in JS.  Peter and I were
mostly guessing since, if you think about it, we were basically doing Flex
until we got into FlexJS and are not experienced in HTML/JS.

So, fundamentally, if you have to stack things vertically, should you use
display:block?  If you have to line up a bunch of divs horizontally,
should you use display:inline-block?

Is there a better way to do BasicLayout?  We ended up using a completely
handwritten set of code to essentially make everything use absolute
positioning.

Is border-box working as expected?  Do you set the height/width to include
the padding or not?

I think some layouts can use CSS but others have to be written in code to
override default browser behavior.  But I'd love to be wrong about that
(at least, without relying on latest browsers or polyfills).

And finally, are there ways we can call the layout fewer times than we
currently do?

For sure, we need to the the JS side right and then worry about the SWF
side.  I think there are way fewer behavior issues on the SWF side to deal
with.

My 2 cents,
-Alex

On 2/21/17, 12:35 PM, "Peter Ent"  wrote:

>I think this is generally a good approach.
>
>I've been thinking that we have some refactoring to do which might help.
>For instance, Core should probably be edited to include interfaces,
>events, and whatever else works across all packages. HTML should probably
>be just the HTML classes (Div, H1, TextNode, etc) so anyone that wants
>HTML+ActionScript can use that and then use CSS to do all their layouts;
>HTML would not have a SWF version.
>
>Then Basic could be SWF & JS with layouts that are light on the JS side
>using CSS and AS code to mimic them on the SWF side. Express would do what
>it is doing now and compose components by extending the Basic set and
>adding common beads.
>
>I've been hung up with the JS side having stuck on the display and
>position values and deferring them might be the best solution.
>
>—peter
>
>On 2/21/17, 2:25 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>
>wrote:
>
>>Hi Peter,
>>
>>it seems HTML rely for this task heavily on CSS to the point that almost
>>nothing is done in html or js code.
>>So maybe we are not in the right way for HTML platform and we should make
>>our code be mainly CSS.
>>An example is here:
>>
>>https://css-tricks.com/snippets/sass/placing-items-circle/
>>
>>Another point is SWF. I'm not focusing in that output and even I didn't
>>compile to SWF for long time, so don't know how
>>is looking, but for what I saw in other discussions seems that Flash
>>needs
>>to implement the old Flex architecture of
>>updateDisplayList to manage refresh to avoid continuous redrawing of the
>>screen.
>>
>>So my bet is that our AS3 layout components should do:
>>
>>1.- In JS -> add className to "some-class-layout" (for example for
>>circle,
>>if we have circle-layout, we should have a "circleLayout" css class
>>selector, that we could assign to out flexjs "list component"
>>
>>2.- in SWF -> we should stick with the way this was done in Flex4 but
>>implementing as a bead and with the "updateDisplayList" performance
>>
>>What do you think?
>>
>>
>>
>>
>>2017-02-21 20:10 GMT+01:00 Peter Ent :
>>
>>> A lot of this work is mine and it seems to need to be thought through
>>>once
>>> again. The dichotomy of SWF & JS has presented problems for me in the
>>>past.
>>>
>>> Maybe the layouts, for JS platform, should do as little as possible,
>>> replying on CSS as much as possible. Then make the SWF platform mimic
>>>that.
>>>
>>> One issue that comes up for me is that we automatically set display and
>>> position for every element soon after its created. If you were to
>>> hand-write the HTML you probably would not do that.
>>>
>>> So perhaps FlexJS should not set these styles at all and instead let
>>>the
>>> layout set them if the layout even needs to do that.
>>>
>>> Thoughts?
>>> ‹peter
>>>
>>> On 2/21/17, 1:42 PM, "Harbs"  wrote:
>>>
>>> >We¹re really struggling with layout.
>>> >
>>> >Yishay just mentioned the fact that padding is not working, but the
>>> >problems seem to go much deeper than that.
>>> >
>>> >1. VerticalLayout has the following code:
>>> >   for (i = 0; i < n; i++)
>>> >   {
>>> >   var child:WrappedHTMLElement =
>>> children[i];
>>> >   child.flexjs_wrapper.
>>> setDisplayStyleForLayout('block');
>>> > 

Re: [FlexJS] resize event not working?

[Justin Mclean]

Hi,

> Looks like you’re using a flash event instead of the flexjs one.

Thanks for that I tried that as well, but still doesn’t work.

I can see the Resize bead is doing this:
 window.addEventListener('resize', 
org.apache.flex.utils.Language.closure(this.resizeHandler, this, 
'resizeHandler'), false);

And dispatches a “sizeChanged” event like so:
initialView.dispatchEvent('sizeChanged’);

Any reason for the event name change?

So this code below will work. But it seems a rather roundabout way of doing it.


http://ns.adobe.com/mxml/2009";
xmlns:js="library://ns.apache.org/flexjs/basic" 
initialize="init()">


















  


Thanks,
Justin

Re: [FlexJS] MDL - Dynamic Child Problem

[Alex Harui]

Well, I agree that most FlexJS users will not be more productive having to
assemble everything from tons of little beads, and that's why I've been
saying for quite a while that I expect heavier component sets like Express
to be more popular.

That said, we don't want the compiler generating code.  With FlexJS, we
are trying hard not to generate any code out of the compiler.  I think I
have it down to just the getter/setters for [Bindable].  Everything else
is converted to data structures so the framework can interpret the data
structures.  The reason is mostly practical. It is scary for most folks to
change the compiler.  Better to put the bug fixing in the framework code
where most folks are more familiar.  But also, it means that different
frameworks can do different things with the data, and that allows testing
harnesses to muck with what actually happens which is useful if you want
to slip in mocks or test-only versions of things.

Express components could instantiate beads in the setter.  That sounds
like a pattern worth more investigation.  Basic components won't because
that would involve extending the model beyond the basic model.  A Basic
button doesn't even have a model, it doesn't have text or image
properties, or a disabled property.  A Basic TextButton adds on a
text/html property.  And you plug in the DisableBead without adding to the
model.  The Express Button aggregates all of those things and probably
more.

In the end, all of this PAYG and beads and composition comes back to DRY.
We encapsulate small chunks of useful code in beads so nobody else has to
write and debug it.  We compose it into heavier aggregations in various
ways: as a strand full of beads so individual beads can be replaced, and
as "inlined" heavy components so you don't have to waste time with all of
these little objects if you know you are going to use all of them most of
the time.

One final thought:  I think of large hardware stores.  You go to the tool
area and the number of screwdrivers or drills is overwhelming.  They are
all slightly different, optimized for some particular scenario.  The same
will be true for FlexJS and beads. But the cool thing about software is
that it will have the best "return policy".  Grab a bead, try it, toss it
if it doesn't work, check the reviews for what one to try next.  Most of
us manage to choose a screwdriver or drill that makes us happy.  We will
be able to choose beads as well, but we will need a good online
catalog/store for beads.  I hope to see us build one with FlexJS of course.

My 2 cents,
-Alex

On 2/21/17, 5:03 PM, "Guild, Jason A (DFG)"  wrote:

>THIS.
>
>As an outsider looking in who also doesn't have much experience with
>FlexJS, I see the approach outlined below to be the best compromise
>between the "FlexJS the API" and PAYG for efficiency.
>
>I know it's just a step on the way, and I am positive that Express will
>be a big help, but I've been alarmed at the number of special-purpose
>beads and tags which have been proposed and implemented to get stuff
>done in a way that was what made Flex so productive in the first place.
>The developer is supposed to browse all of them and know which ones to
>compose together to get the basics?
>
>The approach given below effectively treats PAYG as a course-grained
>optimization pass.
>If the compiler detects that some feature is used and then hooks up the
>appropriate bead automatically then the developer just has to use the
>API and gets PAYG out-of-the-box. If the developer doesn't use a feature
>then the compiler doesn't generate code to set it up.
>
>Powerful concept.
>Jason
>
>
>On 2/21/2017 6:11, Dev LFM wrote:
>> I did not tried yet FlesJS, but I'm listening every post. I think those
>> beads should be added automatically and internally only if needed, ex:
>>
>> if some component have a binding tag like visible="{model.show}", this
>> would automatically add 2 beads, the binding bead and the
>>visibilitybead.
>> What I mean is that every component could be PAYG in the way that are
>>the
>> very basic in the beginning, but as the dev requires functionalities, it
>> should add them automatically. In the cases that the dev wants custom
>> beads, then it must overrides the method that set those beads.
>>
>> Maybe I'm missing some point..
>>
>> 2017-02-21 14:59 GMT+00:00 yishayw :
>>
>>> I agree. If you think this bead will be used very often you can create
>>>a
>>> subclass that bakes it in. ImageButton in Express is probably a good
>>> example, though I would use StrandUtils to save some code lines.
>>>
>>>
>>>
>>> --
>>> View this message in context: http://apache-flex-
>>> development.247.n4.nabble.com/FlexJS-MDL-Dynamic-Child-
>>> Problem-tp59595p59712.html
>>> Sent from the Apache Flex Development mailing list archive at
>>>Nabble.com.
>>>
>

Re: [FlexJS] MDL - Dynamic Child Problem

[Alex Harui]

On 2/21/17, 11:51 AM, "piotrz"  wrote:

>One thing which I wanted to add to make you more understand.
>
>1) If component is instantiated in mxml and this component has added
>UpgradeElement as default - upgradeElement method from MDL will not be
>fired
>- Cause "componentHandler" do not exists yet.
>2) Once web is loaded and some component is created - logic will fire.
>
>I will wait for others voice also...

I don't think I fully understand the issue.  A summary of what code needs
to be run when might help.

FlexJS should always be PAYG in it implementations, but a library like MDL
can and should also look to improve developer productivity in general.
So, if there is some method that needs to be called in order to
dynamically add a child after page load we should see if that code can get
run on-demand, instead of just-in-case.  If StackOverflow shows that folks
are frequently forgetting to run this code, if we can run it for them, it
will be an advantage for FlexJS.

We should be able to control when/if such code runs by controlling the
lifecycle.  IMO, it is fine to say that folks must use mdl:Application
instead of basic:Application and mdl:Container instead of basic:Container
if that gives you control over the lifecycle that you need in order to
help your customer.  Mixing and matching from different component sets
doesn't need to be a guarantee.  Bonus if it works, but, IMO, no big deal
if it doesn't.

IMO, if you can wrap calls to addChild, you can figure out whether page
load has happened and run code for the user.  You also have the option to
postpone the initial DOM setup until after page loads.  IIRC, Cordova
Applications wait until Cordova gets setup before creates the DOM.  The
CSSFontFaceBead delays the DOM setup until after a font loads.  However,
if there is performance improvements to setting up the initial DOM without
calling this dynamic code, that's fine too.  Set a flag once the page load
is complete.

HTH,
-Alex

FW: [FlexJS] resize event not working?

[Yishay Weiss]

From: Yishay Weiss
Sent: Wednesday, February 22, 2017 8:07 AM
To: Justin Mclean
Subject: RE: [FlexJS] resize event not working?


Looks like you’re using a flash event instead of the flexjs one.



From: Justin Mclean
Sent: Wednesday, February 22, 2017 6:12 AM
To: dev@flex.apache.org
Subject: [FlexJS] resize event not working?



Hi,

This code doesn’t seem to work - anyone have any ideas why?

I tried with and with out the bead and also tried “this.” instead of “view.”


http://ns.adobe.com/mxml/2009";
xmlns:js="library://ns.apache.org/flexjs/basic" 
initialize="init()">



















BTW this:

public function init():void {
this.addEventListener(flash.events.Event.RESIZE, resized);
}

Also gives this warning when compiling:

WARNING - variable flash is undeclared
  this.addEventListener(flash.events.Event.RESIZE, 
org.apache.flex.utils.Language.closure(this.resized, this, 'resized'));

Thanks,
Justin

[FlexJS] resize event not working?

[Justin Mclean]

Hi,

This code doesn’t seem to work - anyone have any ideas why?

I tried with and with out the bead and also tried “this.” instead of “view.”


http://ns.adobe.com/mxml/2009";
xmlns:js="library://ns.apache.org/flexjs/basic" 
initialize="init()">



















BTW this:

public function init():void {
this.addEventListener(flash.events.Event.RESIZE, resized);
}

Also gives this warning when compiling:

WARNING - variable flash is undeclared
  this.addEventListener(flash.events.Event.RESIZE, 
org.apache.flex.utils.Language.closure(this.resized, this, 'resized'));

Thanks,
Justin

[FlexJS] Horizontal list missing scrollbar

[Justin Mclean]

Hi,

I can get list with vertical scrolling working, although it’s not obvious that 
there is a scrollbar in some cases.

But I’m unable horizontal lists to work. I may be missing something or this may 
be a bug. Anyone got this to work?

I was trying to make a horizontal list like so:


http://ns.adobe.com/mxml/2009";
xmlns:js="library://ns.apache.org/flexjs/basic">























It compiles but the text wraps over two lines and no horizontal scroll bar 
shows.

I also note that with list the cursor keys and space bar don’t work as i would 
of expected.

Thanks,
Justin

Re: [FlexJS] MDL - Dynamic Child Problem

[Guild, Jason A (DFG)]

THIS.

As an outsider looking in who also doesn't have much experience with 
FlexJS, I see the approach outlined below to be the best compromise 
between the "FlexJS the API" and PAYG for efficiency.


I know it's just a step on the way, and I am positive that Express will 
be a big help, but I've been alarmed at the number of special-purpose 
beads and tags which have been proposed and implemented to get stuff 
done in a way that was what made Flex so productive in the first place. 
The developer is supposed to browse all of them and know which ones to 
compose together to get the basics?


The approach given below effectively treats PAYG as a course-grained 
optimization pass.
If the compiler detects that some feature is used and then hooks up the 
appropriate bead automatically then the developer just has to use the 
API and gets PAYG out-of-the-box. If the developer doesn't use a feature 
then the compiler doesn't generate code to set it up.


Powerful concept.
Jason


On 2/21/2017 6:11, Dev LFM wrote:

I did not tried yet FlesJS, but I'm listening every post. I think those
beads should be added automatically and internally only if needed, ex:

if some component have a binding tag like visible="{model.show}", this
would automatically add 2 beads, the binding bead and the visibilitybead.
What I mean is that every component could be PAYG in the way that are the
very basic in the beginning, but as the dev requires functionalities, it
should add them automatically. In the cases that the dev wants custom
beads, then it must overrides the method that set those beads.

Maybe I'm missing some point..

2017-02-21 14:59 GMT+00:00 yishayw :


I agree. If you think this bead will be used very often you can create a
subclass that bakes it in. ImageButton in Express is probably a good
example, though I would use StrandUtils to save some code lines.



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

[4.16.0] # Apache Flex SDK 4.16.0 nightly build 240: Successful

[flex . ci . builds]

flex-sdk_release-candidate - Build #240 - Successful

Changes since last build:
No changes

For more information, check the console output at 
http://apacheflexbuild.cloudapp.net:8080/job/flex-sdk_release-candidate/240/.

Re: [FlexJS]Layout redux

[piotrz]

+1 for that.

Piotr



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

Re: [FlexJS]Layout redux

[Justin Mclean]

Hi,

> Yishay just mentioned the fact that padding is not working

It not working for me either - see 
https://issues.apache.org/jira/browse/FLEX-35274

> This seems totally wrong. Why is the padding being added when we’re using 
> box-sizing: border-box?

Also seems wrong to me.

> 3. Percentage size seems to be set based on the children rather than the 
> parents.

It's also basically impossible to include percent and fixes sizes in a layout.

Thanks,
Justin

Re: [FlexJS]Layout redux

[Peter Ent]

I think this is generally a good approach.

I've been thinking that we have some refactoring to do which might help.
For instance, Core should probably be edited to include interfaces,
events, and whatever else works across all packages. HTML should probably
be just the HTML classes (Div, H1, TextNode, etc) so anyone that wants
HTML+ActionScript can use that and then use CSS to do all their layouts;
HTML would not have a SWF version.

Then Basic could be SWF & JS with layouts that are light on the JS side
using CSS and AS code to mimic them on the SWF side. Express would do what
it is doing now and compose components by extending the Basic set and
adding common beads.

I've been hung up with the JS side having stuck on the display and
position values and deferring them might be the best solution.

—peter

On 2/21/17, 2:25 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Peter,
>
>it seems HTML rely for this task heavily on CSS to the point that almost
>nothing is done in html or js code.
>So maybe we are not in the right way for HTML platform and we should make
>our code be mainly CSS.
>An example is here:
>
>https://css-tricks.com/snippets/sass/placing-items-circle/
>
>Another point is SWF. I'm not focusing in that output and even I didn't
>compile to SWF for long time, so don't know how
>is looking, but for what I saw in other discussions seems that Flash needs
>to implement the old Flex architecture of
>updateDisplayList to manage refresh to avoid continuous redrawing of the
>screen.
>
>So my bet is that our AS3 layout components should do:
>
>1.- In JS -> add className to "some-class-layout" (for example for circle,
>if we have circle-layout, we should have a "circleLayout" css class
>selector, that we could assign to out flexjs "list component"
>
>2.- in SWF -> we should stick with the way this was done in Flex4 but
>implementing as a bead and with the "updateDisplayList" performance
>
>What do you think?
>
>
>
>
>2017-02-21 20:10 GMT+01:00 Peter Ent :
>
>> A lot of this work is mine and it seems to need to be thought through
>>once
>> again. The dichotomy of SWF & JS has presented problems for me in the
>>past.
>>
>> Maybe the layouts, for JS platform, should do as little as possible,
>> replying on CSS as much as possible. Then make the SWF platform mimic
>>that.
>>
>> One issue that comes up for me is that we automatically set display and
>> position for every element soon after its created. If you were to
>> hand-write the HTML you probably would not do that.
>>
>> So perhaps FlexJS should not set these styles at all and instead let the
>> layout set them if the layout even needs to do that.
>>
>> Thoughts?
>> ‹peter
>>
>> On 2/21/17, 1:42 PM, "Harbs"  wrote:
>>
>> >We¹re really struggling with layout.
>> >
>> >Yishay just mentioned the fact that padding is not working, but the
>> >problems seem to go much deeper than that.
>> >
>> >1. VerticalLayout has the following code:
>> >   for (i = 0; i < n; i++)
>> >   {
>> >   var child:WrappedHTMLElement =
>> children[i];
>> >   child.flexjs_wrapper.
>> setDisplayStyleForLayout('block');
>> >   if (child.style.display ===
>>'none')
>> >   {
>> >   child.flexjs_wrapper.
>> setDisplayStyleForLayout('block');
>> >   }
>> >   else
>> >   {
>> >   // block elements don't
>> measure width correctly so set to inline
>> >for a second
>> >   child.style.display =
>> 'inline-block';
>> >   maxWidth =
>> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
>> >   child.style.display =
>> 'block';
>> >   }
>> >   child.flexjs_wrapper.
>> dispatchEvent('sizeChanged');
>> >   }
>> >
>> >There is a number of problems that I can see with this. Firstly, it¹s
>> >horribly inefficient:
>> >   child.style.display =
>> 'inline-block';
>> >   maxWidth =
>> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
>> >The above will force a browser redraw at every step of the loop. If you
>> >have hundreds of children, there will be hundreds of redraws just to
>> >figure out the children width. If anything, there should probably be
>> >three loops: One to set the inline-blocks, The second to measure all
>>the
>> >children (the first measure would trigger a redraw, but subsequent ones
>> >not) The third to set inline-block back.
>> >
>> >Secondly, t

Re: [FlexJS] MDL - Dynamic Child Problem

[piotrz]

One thing which I wanted to add to make you more understand.

1) If component is instantiated in mxml and this component has added
UpgradeElement as default - upgradeElement method from MDL will not be fired
- Cause "componentHandler" do not exists yet.
2) Once web is loaded and some component is created - logic will fire.

I will wait for others voice also...
Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59733.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS][SpriteFlexJS] DEFINES not in SpriteJS

[Josh Tynjala]

COMPILE::JS and COMPILE:SWC are just regular compile-time constants. As far
as I know, they receive no special treatment from the compiler. It's just a
convention used by the FlexJS framework projects to make the components
exclude certain code on some platforms. If you're targeting one platform,
there shouldn't be any need to exclude anything, so this project shouldn't
need COMPILE::JS at all.

Why do you feel that COMPILE::JS is needed?

- Josh

On Tue, Feb 21, 2017 at 11:12 AM, Carlos Rovira 
wrote:

> Hi,
>
> the problem arised by Chris in SpriteFlexJS branch shows that there's no
> COMPILE::JS or COMPILE::SWF. Since SpriteFlexJS is only JS, seems Lizhi
> doesn't need SWF platform.
>
> So I think he compiles in a way that only target JS platform and compiler
> doesn't fail when COMPILE::JS is not found. How does he make that? Or how
> could I do something like this?
>
> If we want to have SpriteFlexJS with us, I think one of the things to do is
> add those COMPILE::JS to the code.
>
> What do you think?
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>

Re: [FlexJS] MDL - Dynamic Child Problem

[Carlos Rovira]

Hi,

I always try to extrapolate from what I see people are doing in MDL. I
didn't have the time to search too much, but seems people as the perform
something dinamic they use the method, so something "external" is done, and
that's the same approach I proposed with the static utility class. That
class could as well have some param to loop in child elements to make it
more usable.

the interface proposed could be another option, is not introducing the bead
by default, so is better option, since we don't have the code instantiated
at runtime for each component, but adds the code to the class what seems to
me not as PAYG as Util.

Hope others like Alex could give us thoughs about this since seems each one
is very happy with his solution ;)

thanks



2017-02-21 19:56 GMT+01:00 piotrz :

> I went through the comments and I see that voices rather saying that we
> shouldn't make automatic upgrades for the components, but since it is not
> easy add this ability as an util, maybe we should introduce an interface -
> IDynamic with property IsDynamic - setted by constructor or traditionally.
> (of course I'm open for naming)
>
> If user set it we will add Bead appropriately.
>
> Is it more PAYG ?
>
> Piotr
>
>
>
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context: http://apache-flex-
> development.247.n4.nabble.com/FlexJS-MDL-Dynamic-Child-
> Problem-tp59595p59726.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]Layout redux

[Carlos Rovira]

Hi Peter,

it seems HTML rely for this task heavily on CSS to the point that almost
nothing is done in html or js code.
So maybe we are not in the right way for HTML platform and we should make
our code be mainly CSS.
An example is here:

https://css-tricks.com/snippets/sass/placing-items-circle/

Another point is SWF. I'm not focusing in that output and even I didn't
compile to SWF for long time, so don't know how
is looking, but for what I saw in other discussions seems that Flash needs
to implement the old Flex architecture of
updateDisplayList to manage refresh to avoid continuous redrawing of the
screen.

So my bet is that our AS3 layout components should do:

1.- In JS -> add className to "some-class-layout" (for example for circle,
if we have circle-layout, we should have a "circleLayout" css class
selector, that we could assign to out flexjs "list component"

2.- in SWF -> we should stick with the way this was done in Flex4 but
implementing as a bead and with the "updateDisplayList" performance

What do you think?




2017-02-21 20:10 GMT+01:00 Peter Ent :

> A lot of this work is mine and it seems to need to be thought through once
> again. The dichotomy of SWF & JS has presented problems for me in the past.
>
> Maybe the layouts, for JS platform, should do as little as possible,
> replying on CSS as much as possible. Then make the SWF platform mimic that.
>
> One issue that comes up for me is that we automatically set display and
> position for every element soon after its created. If you were to
> hand-write the HTML you probably would not do that.
>
> So perhaps FlexJS should not set these styles at all and instead let the
> layout set them if the layout even needs to do that.
>
> Thoughts?
> ‹peter
>
> On 2/21/17, 1:42 PM, "Harbs"  wrote:
>
> >We¹re really struggling with layout.
> >
> >Yishay just mentioned the fact that padding is not working, but the
> >problems seem to go much deeper than that.
> >
> >1. VerticalLayout has the following code:
> >   for (i = 0; i < n; i++)
> >   {
> >   var child:WrappedHTMLElement =
> children[i];
> >   child.flexjs_wrapper.
> setDisplayStyleForLayout('block');
> >   if (child.style.display === 'none')
> >   {
> >   child.flexjs_wrapper.
> setDisplayStyleForLayout('block');
> >   }
> >   else
> >   {
> >   // block elements don't
> measure width correctly so set to inline
> >for a second
> >   child.style.display =
> 'inline-block';
> >   maxWidth =
> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
> >   child.style.display =
> 'block';
> >   }
> >   child.flexjs_wrapper.
> dispatchEvent('sizeChanged');
> >   }
> >
> >There is a number of problems that I can see with this. Firstly, it¹s
> >horribly inefficient:
> >   child.style.display =
> 'inline-block';
> >   maxWidth =
> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
> >The above will force a browser redraw at every step of the loop. If you
> >have hundreds of children, there will be hundreds of redraws just to
> >figure out the children width. If anything, there should probably be
> >three loops: One to set the inline-blocks, The second to measure all the
> >children (the first measure would trigger a redraw, but subsequent ones
> >not) The third to set inline-block back.
> >
> >Secondly, there¹s only a need to measure the children if the container is
> >sized to content. If the container has a fixed width or a percentage
> >width, I don¹t see why the children should be measured at all. The only
> >exception I can see is if there is overflow:auto.
> >
> >Thirdly, I don¹t understand how setting the child to inline-block helps.
> >What about the grandchildren? Don¹t those need to be measured too?
> >Fourthly, Both Horizontal and VerticalLayout have code which temporarily
> >sets inline-block. BasicLayout does not, and I don¹t understand why
> >there¹s a difference. (BasicLayout has the same re-rendering problem
> >though.)
> >2.
> >   if (!hasWidth && n > 0 &&
> !isNaN(maxWidth)) {
> >   var pl:String =
> scv['padding-left'];
> >   var pr:String =
> scv['padding-right'];
> >   var npl:int =
> parseInt(pl.substring(0, pl.length - 2), 10);
> >  

[FlexJS][SpriteFlexJS] DEFINES not in SpriteJS

[Carlos Rovira]

Hi,

the problem arised by Chris in SpriteFlexJS branch shows that there's no
COMPILE::JS or COMPILE::SWF. Since SpriteFlexJS is only JS, seems Lizhi
doesn't need SWF platform.

So I think he compiles in a way that only target JS platform and compiler
doesn't fail when COMPILE::JS is not found. How does he make that? Or how
could I do something like this?

If we want to have SpriteFlexJS with us, I think one of the things to do is
add those COMPILE::JS to the code.

What do you think?

-- 
Carlos Rovira
http://about.me/carlosrovira

Re: [FlexJS]Layout redux

[Peter Ent]

A lot of this work is mine and it seems to need to be thought through once
again. The dichotomy of SWF & JS has presented problems for me in the past.

Maybe the layouts, for JS platform, should do as little as possible,
replying on CSS as much as possible. Then make the SWF platform mimic that.

One issue that comes up for me is that we automatically set display and
position for every element soon after its created. If you were to
hand-write the HTML you probably would not do that.

So perhaps FlexJS should not set these styles at all and instead let the
layout set them if the layout even needs to do that.

Thoughts?
‹peter

On 2/21/17, 1:42 PM, "Harbs"  wrote:

>We¹re really struggling with layout.
>
>Yishay just mentioned the fact that padding is not working, but the
>problems seem to go much deeper than that.
>
>1. VerticalLayout has the following code:
>   for (i = 0; i < n; i++)
>   {
>   var child:WrappedHTMLElement = 
> children[i];
>   
> child.flexjs_wrapper.setDisplayStyleForLayout('block');
>   if (child.style.display === 'none')
>   {
>   
> child.flexjs_wrapper.setDisplayStyleForLayout('block');
>   } 
>   else 
>   {
>   // block elements don't measure 
> width correctly so set to inline
>for a second
>   child.style.display = 
> 'inline-block';
>   maxWidth = Math.max(maxWidth, 
> child.offsetLeft + child.offsetWidth);
>   child.style.display = 'block';
>   }
>   
> child.flexjs_wrapper.dispatchEvent('sizeChanged');
>   }
>
>There is a number of problems that I can see with this. Firstly, it¹s
>horribly inefficient:
>   child.style.display = 
> 'inline-block';
>   maxWidth = Math.max(maxWidth, 
> child.offsetLeft + child.offsetWidth);
>The above will force a browser redraw at every step of the loop. If you
>have hundreds of children, there will be hundreds of redraws just to
>figure out the children width. If anything, there should probably be
>three loops: One to set the inline-blocks, The second to measure all the
>children (the first measure would trigger a redraw, but subsequent ones
>not) The third to set inline-block back.
>
>Secondly, there¹s only a need to measure the children if the container is
>sized to content. If the container has a fixed width or a percentage
>width, I don¹t see why the children should be measured at all. The only
>exception I can see is if there is overflow:auto.
>
>Thirdly, I don¹t understand how setting the child to inline-block helps.
>What about the grandchildren? Don¹t those need to be measured too?
>Fourthly, Both Horizontal and VerticalLayout have code which temporarily
>sets inline-block. BasicLayout does not, and I don¹t understand why
>there¹s a difference. (BasicLayout has the same re-rendering problem
>though.)
>2.
>   if (!hasWidth && n > 0 && !isNaN(maxWidth)) {
>   var pl:String = scv['padding-left'];
>   var pr:String = scv['padding-right'];
>   var npl:int = parseInt(pl.substring(0, 
> pl.length - 2), 10);
>   var npr:int = parseInt(pr.substring(0, 
> pr.length - 2), 10);
>   maxWidth += npl + npr;
>   contentView.width = maxWidth;
>   }
>
>This seems totally wrong. Why is the padding being added when we¹re using
>box-sizing: border-box?
>
>3. Percentage size seems to be set based on the children rather than the
>parents.
>
>4. I¹m not sure I understand the layout lifecycle very well. We have had
>cases where children did not seem to be layout, and forcing a layout
>seemed to be very difficult to do.
>
>Harbs

Re: [FlexJS] - Is FlexJS ready for production?

[Carlos Rovira]

Hi Chris,

thanks for seeing the problem, I don't think that could be that... I'll be
creating another thread to see how should I overcome this problem without
the need to apply all DEFINES all over the code...

Thanks!




El 21 de febrero de 2017, 17:13, Christofer Dutz 
escribió:

> Strange … I could swear I pushed it, well I re-pushed and verified it’s in
> there now ☺
>
> Chris
>
> Am 21.02.17, 16:27 schrieb "carlos.rov...@gmail.com im Auftrag von Carlos
> Rovira"  carlos.rov...@codeoscopic.com>:
>
> I did a rebase of the branch against develop for better handling
>
> El 21 de febrero de 2017, 16:26, Carlos Rovira <
> carlos.rov...@codeoscopic.com> escribió:
>
> > Hi Chris,
> >
> > I think you finaly didn't commit that changes right? I don't see any
> > commit pending to pull in my source tree for "feature/spriteflexjs-
> > refactor"
> > thanks
> >
> > El 17 de febrero de 2017, 21:14, Carlos Rovira <
> > carlos.rov...@codeoscopic.com> escribió:
> >
> >> Great Chris!,
> >> as I'm focused with AMF/RemoteObject, I try to end that and then go
> to
> >> that branch.
> >>
> >> Thanks for get that problem solved! :))
> >>
> >> 2017-02-17 17:30 GMT+01:00 Christofer Dutz <
> christofer.d...@c-ware.de>:
> >>
> >>> Hi Carlos,
> >>>
> >>> I just had a look and your code had the problem, that the import
> was a
> >>> JS only import and your code was JS-only. I added some defines and
> I
> >>> compiled. I checked in the changes on your branch so you can have
> a look.
> >>>
> >>> Chris
> >>>
> >>> Am 15.02.17, 20:36 schrieb "carlos.rov...@gmail.com im Auftrag von
> >>> Carlos Rovira"  >>> carlos.rov...@codeoscopic.com>:
> >>>
> >>> Hi
> >>>
> >>> just recreated all from scratch and made a new project based
> on MDL
> >>> with
> >>> the some new code. Is a the most basic to keep things simple
> >>> I uploaded to a new branch  " feature/spriteflexjs-refactor"
> >>> hope you guys could try it and get some clue of what's
> happening.
> >>>
> >>> Thanks
> >>>
> >>>
> >>> 2017-02-15 20:24 GMT+01:00 Alex Harui :
> >>>
> >>> >
> >>> >
> >>> > On 2/15/17, 11:20 AM, "Christofer Dutz" <
> christofer.d...@c-ware.de>
> >>> wrote:
> >>> >
> >>> > >Well actually I noticed this too this afternoon too …
> >>> typedef/externs
> >>> > >should always be added as “scope=runtime”.
> >>> >
> >>> > I don't think that's true.  Runtime scope puts you on the
> >>> > external-library-path.  GCL needs to be on the library-path.
> >>> >
> >>> > -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.
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> Carlos Rovira
> >> Director General
> >> M: +34 607 22 60 05 <607%2022%2060%2005>
> >> 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
> >> docum

Re: [FlexJS] MDL - Dynamic Child Problem

[piotrz]

I went through the comments and I see that voices rather saying that we
shouldn't make automatic upgrades for the components, but since it is not
easy add this ability as an util, maybe we should introduce an interface -
IDynamic with property IsDynamic - setted by constructor or traditionally.
(of course I'm open for naming)

If user set it we will add Bead appropriately. 

Is it more PAYG ?

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59726.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

[FlexJS]Layout redux

[Harbs]

We’re really struggling with layout.

Yishay just mentioned the fact that padding is not working, but the problems 
seem to go much deeper than that.

1. VerticalLayout has the following code:
for (i = 0; i < n; i++)
{
var child:WrappedHTMLElement = 
children[i];

child.flexjs_wrapper.setDisplayStyleForLayout('block');
if (child.style.display === 'none') 
{

child.flexjs_wrapper.setDisplayStyleForLayout('block');
} 
else 
{
// block elements don't measure 
width correctly so set to inline for a second
child.style.display = 
'inline-block';
maxWidth = Math.max(maxWidth, 
child.offsetLeft + child.offsetWidth);
child.style.display = 'block';
}

child.flexjs_wrapper.dispatchEvent('sizeChanged');
}

There is a number of problems that I can see with this. Firstly, it’s horribly 
inefficient:
child.style.display = 
'inline-block';
maxWidth = Math.max(maxWidth, 
child.offsetLeft + child.offsetWidth);
The above will force a browser redraw at every step of the loop. If you have 
hundreds of children, there will be hundreds of redraws just to figure out the 
children width. If anything, there should probably be three loops: One to set 
the inline-blocks, The second to measure all the children (the first measure 
would trigger a redraw, but subsequent ones not) The third to set inline-block 
back.

Secondly, there’s only a need to measure the children if the container is sized 
to content. If the container has a fixed width or a percentage width, I don’t 
see why the children should be measured at all. The only exception I can see is 
if there is overflow:auto.

Thirdly, I don’t understand how setting the child to inline-block helps. What 
about the grandchildren? Don’t those need to be measured too?
Fourthly, Both Horizontal and VerticalLayout have code which temporarily sets 
inline-block. BasicLayout does not, and I don’t understand why there’s a 
difference. (BasicLayout has the same re-rendering problem though.)
2.
if (!hasWidth && n > 0 && !isNaN(maxWidth)) {
var pl:String = scv['padding-left'];
var pr:String = scv['padding-right'];
var npl:int = parseInt(pl.substring(0, 
pl.length - 2), 10);
var npr:int = parseInt(pr.substring(0, 
pr.length - 2), 10);
maxWidth += npl + npr;
contentView.width = maxWidth;
}

This seems totally wrong. Why is the padding being added when we’re using 
box-sizing: border-box?

3. Percentage size seems to be set based on the children rather than the 
parents.

4. I’m not sure I understand the layout lifecycle very well. We have had cases 
where children did not seem to be layout, and forcing a layout seemed to be 
very difficult to do.

Harbs

Re: [FlexJS] MDL - Dynamic Child Problem

[piotrz]

Maybe I will commit RadioButton changes and you will see - if I will be able
to even upgrade it.

Let say that our component consists with:



 

Checkbox and Span need to be upgraded, so inside my custom component I will
create:

var cbx = new CheckBox(); - If it is upgradable inside I won't have add
anything but if not -> cbx.addBead(new UpgradeElement());
var span = new Span();
span.addBead(new UpgradeElement());

etc.

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59724.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

[sankar]

Carlos Rovira wrote
> What about to have a MDLUtils or UpgradeMDLUtils class with static
> methods?
> So people that would create a component will do
> "UpgradeUtils.upgradeElement(buttonToUpgrade);"
> In this way people using a button 90% of times will not be affected by
> that
> overhead.
> (I'm thinking on a general scenario where 80-90% of uses are mxml
> declaration vs 10-20 or less of dynamic creation)

Hi Carlos,

Echoing Piotr's worry with this design, I also has a point I thought you
should consider about. 

The design with 'UpgradeUtils.upgradeElement' maybe find when you adds
single component dynamically. But when you adds a complete external
component consists of many different MDL components, wouldn't be the
procedure will be tricky/complex for 'UpgradeUtils.upgradeElement' method,
to upgrade everything inside?

Thanks!



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

Re: [FlexJS] MDL - TabBarPanel children do not gets flexible sizes

[sankar]

Hi Carlos,

Thank you for sharing your thoughts on this.. 

I tried to watch where it's failing, and then I found
 size wasn't properly updating. 

For some unknown reason, when application starts, NavigationLayoutContent
somehow acquire 1300px it's width; the owner component's width I found is
more than 1300px; But the NavigationLayoutContent never update it's size by
that.

So I overcome the problem to some extent by this way:


> 
> ...
> 
>   
> 
>   
> 
>   
> 
>   
> 
>   
> 
>   
> 
> 
> 

Well, this fix the problem to an extent. Now the NavigationLayoutContent
starts with expected size when application starts; But it do not updates it
size when browser resized. 

Do you suggest something that I can use to make this updateable with browser
resize?

Thanks!



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-MDL-TabBarPanel-children-do-not-gets-flexible-sizes-tp59686p59721.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL - Dynamic Child Problem

[piotrz]

But from the developer point of view I see TextField - if text field has
inside one or three elements to upgrade ? 

As a developer I don't know nothing about component inside - I would like to
use it, dynamically. If I won't upgrade some internal components than
something won't be working. 

For example for RadioButton - ripple options wasn't work when I upgrade only
one part of RadioButton.

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59722.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] - Is FlexJS ready for production?

[Christofer Dutz]

Strange … I could swear I pushed it, well I re-pushed and verified it’s in 
there now ☺

Chris

Am 21.02.17, 16:27 schrieb "carlos.rov...@gmail.com im Auftrag von Carlos 
Rovira" :

I did a rebase of the branch against develop for better handling

El 21 de febrero de 2017, 16:26, Carlos Rovira <
carlos.rov...@codeoscopic.com> escribió:

> Hi Chris,
>
> I think you finaly didn't commit that changes right? I don't see any
> commit pending to pull in my source tree for "feature/spriteflexjs-
> refactor"
> thanks
>
> El 17 de febrero de 2017, 21:14, Carlos Rovira <
> carlos.rov...@codeoscopic.com> escribió:
>
>> Great Chris!,
>> as I'm focused with AMF/RemoteObject, I try to end that and then go to
>> that branch.
>>
>> Thanks for get that problem solved! :))
>>
>> 2017-02-17 17:30 GMT+01:00 Christofer Dutz :
>>
>>> Hi Carlos,
>>>
>>> I just had a look and your code had the problem, that the import was a
>>> JS only import and your code was JS-only. I added some defines and I
>>> compiled. I checked in the changes on your branch so you can have a 
look.
>>>
>>> Chris
>>>
>>> Am 15.02.17, 20:36 schrieb "carlos.rov...@gmail.com im Auftrag von
>>> Carlos Rovira" >> carlos.rov...@codeoscopic.com>:
>>>
>>> Hi
>>>
>>> just recreated all from scratch and made a new project based on MDL
>>> with
>>> the some new code. Is a the most basic to keep things simple
>>> I uploaded to a new branch  " feature/spriteflexjs-refactor"
>>> hope you guys could try it and get some clue of what's happening.
>>>
>>> Thanks
>>>
>>>
>>> 2017-02-15 20:24 GMT+01:00 Alex Harui :
>>>
>>> >
>>> >
>>> > On 2/15/17, 11:20 AM, "Christofer Dutz" 

>>> wrote:
>>> >
>>> > >Well actually I noticed this too this afternoon too …
>>> typedef/externs
>>> > >should always be added as “scope=runtime”.
>>> >
>>> > I don't think that's true.  Runtime scope puts you on the
>>> > external-library-path.  GCL needs to be on the library-path.
>>> >
>>> > -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.
>>>
>>>
>>>
>>
>>
>> --
>>
>> Carlos Rovira
>> Director General
>> M: +34 607 22 60 05 <607%2022%2060%2005>
>> 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.
>>
>>
>
>
> --
>
> Carlos Rovira
> Director General
> M: +34 607 22 60 05 <607%2022%2060%2005>
> 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

Re: [FlexJS] MDL - Dynamic Child Problem

[Josh Tynjala]

I think, since the core MDL library doesn't upgrade components by default,
it's okay if the FlexJS wrapper doesn't either. I think we should make sure
it's well documented, though. Maybe with a special section in the MDL
example app.

- Josh

On Feb 21, 2017 7:18 AM, "Carlos Rovira" 
wrote:

What about to have a MDLUtils or UpgradeMDLUtils class with static methods?
So people that would create a component will do
"UpgradeUtils.upgradeElement(buttonToUpgrade);"
In this way people using a button 90% of times will not be affected by that
overhead.
(I'm thinking on a general scenario where 80-90% of uses are mxml
declaration vs 10-20 or less of dynamic creation)



2017-02-21 15:59 GMT+01:00 yishayw :

> I agree. If you think this bead will be used very often you can create a
> subclass that bakes it in. ImageButton in Express is probably a good
> example, though I would use StrandUtils to save some code lines.
>
>
>
> --
> View this message in context: http://apache-flex-development
> .247.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59712.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>



--

Carlos Rovira
Director General
M: +34 607 22 60 05 <607%2022%2060%2005>
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: [Flex JS] Click handler on label fails

[Alex Harui]

On 2/21/17, 12:34 AM, "Justin Mclean"  wrote:

>> We have to decide whether we want labels to be clickable on SWF and JS
>>and make it consistent.
>
>I guess it should not extend UIBase if there no click handler?

It can, but in theory in the dual branch, UIBase wouldn't have click
event.  I'll have to try that out.

Thanks,
-Alex

Re: [FlexJS] MDL - TabBarPanel children do not gets flexible sizes

[Carlos Rovira]

Hi Sankar,

FWIK, Alex and Peter rely on relative positioning to get percent size
handling. But MDL does not use relative positioning at all.
So that should be the problem you have with that property. That's the
trade-off of sets like MDL that are a wrap of an external library and not
a FlexJS natural one.

Maybe the workaround is to see how this is done in natural MDL and
extrapolate a Flex solution. As well, if that solution is generic introduce
it in MDL library for normal use.

Thanks!

Carlos





2017-02-20 14:00 GMT+01:00 sankar :

> Hi,
>
> I noticed that components declared inside a TabBarPanel, do not works with
> "percentWidth" or "percentHeight" properties. This applicable to any
> component that is the immediate child of TabBarPanel.
>
> Is it possible to get them fixed or any bead like DataGridPercentageLayout
> (?)
>
> Thanks!
>
>
>
> --
> View this message in context: http://apache-flex-
> development.247.n4.nabble.com/FlexJS-MDL-TabBarPanel-
> children-do-not-gets-flexible-sizes-tp59686.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] - Is FlexJS ready for production?

[Carlos Rovira]

I did a rebase of the branch against develop for better handling

El 21 de febrero de 2017, 16:26, Carlos Rovira <
carlos.rov...@codeoscopic.com> escribió:

> Hi Chris,
>
> I think you finaly didn't commit that changes right? I don't see any
> commit pending to pull in my source tree for "feature/spriteflexjs-
> refactor"
> thanks
>
> El 17 de febrero de 2017, 21:14, Carlos Rovira <
> carlos.rov...@codeoscopic.com> escribió:
>
>> Great Chris!,
>> as I'm focused with AMF/RemoteObject, I try to end that and then go to
>> that branch.
>>
>> Thanks for get that problem solved! :))
>>
>> 2017-02-17 17:30 GMT+01:00 Christofer Dutz :
>>
>>> Hi Carlos,
>>>
>>> I just had a look and your code had the problem, that the import was a
>>> JS only import and your code was JS-only. I added some defines and I
>>> compiled. I checked in the changes on your branch so you can have a look.
>>>
>>> Chris
>>>
>>> Am 15.02.17, 20:36 schrieb "carlos.rov...@gmail.com im Auftrag von
>>> Carlos Rovira" >> carlos.rov...@codeoscopic.com>:
>>>
>>> Hi
>>>
>>> just recreated all from scratch and made a new project based on MDL
>>> with
>>> the some new code. Is a the most basic to keep things simple
>>> I uploaded to a new branch  " feature/spriteflexjs-refactor"
>>> hope you guys could try it and get some clue of what's happening.
>>>
>>> Thanks
>>>
>>>
>>> 2017-02-15 20:24 GMT+01:00 Alex Harui :
>>>
>>> >
>>> >
>>> > On 2/15/17, 11:20 AM, "Christofer Dutz" 
>>> wrote:
>>> >
>>> > >Well actually I noticed this too this afternoon too …
>>> typedef/externs
>>> > >should always be added as “scope=runtime”.
>>> >
>>> > I don't think that's true.  Runtime scope puts you on the
>>> > external-library-path.  GCL needs to be on the library-path.
>>> >
>>> > -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.
>>>
>>>
>>>
>>
>>
>> --
>>
>> Carlos Rovira
>> Director General
>> M: +34 607 22 60 05 <607%2022%2060%2005>
>> 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.
>>
>>
>
>
> --
>
> Carlos Rovira
> Director General
> M: +34 607 22 60 05 <607%2022%2060%2005>
> 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.
>
>


-- 

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 Dato

Re: [FlexJS] - Is FlexJS ready for production?

[Carlos Rovira]

Hi Chris,

I think you finaly didn't commit that changes right? I don't see any commit
pending to pull in my source tree for "feature/spriteflexjs-refactor"
thanks

El 17 de febrero de 2017, 21:14, Carlos Rovira <
carlos.rov...@codeoscopic.com> escribió:

> Great Chris!,
> as I'm focused with AMF/RemoteObject, I try to end that and then go to
> that branch.
>
> Thanks for get that problem solved! :))
>
> 2017-02-17 17:30 GMT+01:00 Christofer Dutz :
>
>> Hi Carlos,
>>
>> I just had a look and your code had the problem, that the import was a JS
>> only import and your code was JS-only. I added some defines and I compiled.
>> I checked in the changes on your branch so you can have a look.
>>
>> Chris
>>
>> Am 15.02.17, 20:36 schrieb "carlos.rov...@gmail.com im Auftrag von
>> Carlos Rovira" > carlos.rov...@codeoscopic.com>:
>>
>> Hi
>>
>> just recreated all from scratch and made a new project based on MDL
>> with
>> the some new code. Is a the most basic to keep things simple
>> I uploaded to a new branch  " feature/spriteflexjs-refactor"
>> hope you guys could try it and get some clue of what's happening.
>>
>> Thanks
>>
>>
>> 2017-02-15 20:24 GMT+01:00 Alex Harui :
>>
>> >
>> >
>> > On 2/15/17, 11:20 AM, "Christofer Dutz" 
>> wrote:
>> >
>> > >Well actually I noticed this too this afternoon too …
>> typedef/externs
>> > >should always be added as “scope=runtime”.
>> >
>> > I don't think that's true.  Runtime scope puts you on the
>> > external-library-path.  GCL needs to be on the library-path.
>> >
>> > -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.
>>
>>
>>
>
>
> --
>
> Carlos Rovira
> Director General
> M: +34 607 22 60 05 <607%2022%2060%2005>
> 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.
>
>


-- 

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] MDL - Dynamic Child Problem

[Carlos Rovira]

What about to have a MDLUtils or UpgradeMDLUtils class with static methods?
So people that would create a component will do
"UpgradeUtils.upgradeElement(buttonToUpgrade);"
In this way people using a button 90% of times will not be affected by that
overhead.
(I'm thinking on a general scenario where 80-90% of uses are mxml
declaration vs 10-20 or less of dynamic creation)



2017-02-21 15:59 GMT+01:00 yishayw :

> I agree. If you think this bead will be used very often you can create a
> subclass that bakes it in. ImageButton in Express is probably a good
> example, though I would use StrandUtils to save some code lines.
>
>
>
> --
> View this message in context: http://apache-flex-development
> .247.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59712.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>



-- 

Carlos Rovira
Director General
M: +34 607 22 60 05 <607%2022%2060%2005>
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] MDL - Dynamic Child Problem

[Dev LFM]

I did not tried yet FlesJS, but I'm listening every post. I think those
beads should be added automatically and internally only if needed, ex:

if some component have a binding tag like visible="{model.show}", this
would automatically add 2 beads, the binding bead and the visibilitybead.
What I mean is that every component could be PAYG in the way that are the
very basic in the beginning, but as the dev requires functionalities, it
should add them automatically. In the cases that the dev wants custom
beads, then it must overrides the method that set those beads.

Maybe I'm missing some point..

2017-02-21 14:59 GMT+00:00 yishayw :

> I agree. If you think this bead will be used very often you can create a
> subclass that bakes it in. ImageButton in Express is probably a good
> example, though I would use StrandUtils to save some code lines.
>
>
>
> --
> View this message in context: http://apache-flex-
> development.247.n4.nabble.com/FlexJS-MDL-Dynamic-Child-
> Problem-tp59595p59712.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: [FlexJS] MDL - Dynamic Child Problem

[yishayw]

I agree. If you think this bead will be used very often you can create a
subclass that bakes it in. ImageButton in Express is probably a good
example, though I would use StrandUtils to save some code lines.



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

Re: [FlexJS] MDL - Dynamic Child Problem

[piotrz]

Hi Carlos,

Well at some point I agree, but there are components which you won't be able
to simple use this bead:

For example TextField. You cannot do such things:

var textField = new TextField();
textField.addBead(new UpgradeElement()) - cause this bead is registering
host.element and element is not always something what need to be upgraded.
Sometimes upgrades needs some internal components - Take a look how I use
UpgradeElement in TextField.

The other things RadioButton - It's also same or even worse, cause Radio
contains two components inside which need to be upgraded.

If we wanna add possibility to create such basic components dynamically I
don't see any other options. 

This bead is also for someone who will create custom component in FlexJS,
register it and will need to upgrade it during dynamic creation. - That's
the place where PAYG will work fully.

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-MDL-Dynamic-Child-Problem-tp59595p59711.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [Flex JS] Click handler on label fails

[Carlos Rovira]

I remember seeing this as well, but maybe no body did a ticket for it

2017-02-21 9:34 GMT+01:00 Justin Mclean :

> Hi,
>
> > That's been reported before.
>
> I can’t find a JIRA for it. Has one be raised?
>
> > We have to decide whether we want labels to be clickable on SWF and JS
> and make it consistent.
>
> I guess it should not extend UIBase if there no click handler?
>
> Thanks,
> Justin




-- 

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] MDL - Dynamic Child Problem

[Carlos Rovira]

Hi Piotr,

thanks for introducing the UpgradeElement bead. I saw that Button and
TextField add this element by default.
But that breaks IMHO the concept of PAYG. many people can use a button
without the need to have always that bead added. For me is the same example
that with TextField and Prompt or DisplayAsPassword. Is not needed 100% of
times

do you agree?

Thanks



2017-02-21 13:24 GMT+01:00 sankar :

> Hi Piotr,
>
> On a separate thought, this following throws me error in "bin-release"
> version, but "bin-debug" doing good.
>
>
> >   if ("componentHandler" in document.defaultView)
> > {
> >
> > document.defaultView["componentHandler"].upgradeElement(c.positioner);
> > }
>
> I don't know what path you choose to update the window DOM, but you may
> want
> to keep an eye on "bin-release" version. The above code throws me exception
> as this:
>
> TypeError: document.defaultView.componentHandler.Cf is not a function
>
>
> Thanks!
>
>
>
> --
> View this message in context: http://apache-flex-
> development.247.n4.nabble.com/FlexJS-MDL-Dynamic-Child-
> Problem-tp59595p59708.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] MDL - Dynamic Child Problem

[sankar]

Hi Piotr,

On a separate thought, this following throws me error in "bin-release"
version, but "bin-debug" doing good.


>   if ("componentHandler" in document.defaultView)
> {
>   
> document.defaultView["componentHandler"].upgradeElement(c.positioner);
> }

I don't know what path you choose to update the window DOM, but you may want
to keep an eye on "bin-release" version. The above code throws me exception
as this:

TypeError: document.defaultView.componentHandler.Cf is not a function


Thanks!



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

[FlexJS] MDL - TabBar background color

[sankar]

Hi,

I was trying to change background color to TabBar components, so here what I
did in code:


>  tabIdField="href" className="customTabBarSetup"
> style="backgroundColor:#811937">

This changed the background color, but left a portion at left and right:
 

When I debugged the code in Chrome developer tools, I found following
generated HTML against those blue colored blocks:

 

It looks like the blocks are consists of arrow/buttons to scroll the tabs
left/right when there's enough tabs.

But I'm not sure how can I access those blocks in FlexJS and place a
background color style.

Please, suggest.

Thanks!



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

Re: [FlexJS] Spacers and positioning

[yishayw]

That sounds like a good idea. Let me know if I can help.



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

Re: [ApacheCon] Let's make it happen :-)

[Tom Chiverton]

Done.

Tom


On 21/02/17 06:59, piotrz wrote:

Hi Guys,

I saw on facebook created event - Can we add in the event details also link
to our event website?

Did someone post officiall announcement on Twitter?

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/ApacheCon-Let-s-make-it-happen-tp58856p59695.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

Re: [Flex JS] Padding not working as expected

[yishayw]

Justin Mclean wrote
> Here’s the generated HTML:
> 
> <
> div style="display: block;  >
> position: absolute
*
> ; left: 0px; top: 0px; width: 100px; height: 100px;">

> Hello

> 
> 

We just ran into this as well. The problem is that the content view has
absolute positioning (boldfaced).

BTW, the flash version works.




--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Flex-JS-Padding-not-working-as-expected-tp59515p59704.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.