Hi,
I think I understand this now.
When you set x, y on a component, you will be setting the left and top
styles on the HTML element. Setting these properties will no longer set
the position style (which will remain unchanged it has been set).
The Container classes will no longer have a default
We still have to have FlexJS work on both JS and SWF sides with some
compatibility. We could do this:
x,y sets "native" values. Reading them back on SWF vs JS might yield
different results if padding, border, and margins are set on the parent
element. If you don't want your coordinates messed with
This [1] thread talks about the advantages of SWF for JS targeted projects.
[1]
http://apache-flex-development.247.n4.nabble.com/FlexJS-Importance-of-SWF-output-td55843.html#a55849
--
View this message in context:
http://apache-flex-development.247.n4.nabble.com/FlexJS-Coordinate
lex-development.247.n4.nabble.com/FlexJS-Coordinate-Space-tp59924p59964.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Hi,
Probably better to read the first sentence as " ignore the SWF side”, I still
want to code / compile AS (as it pick up more issues) but ignore the SWF output.
> The workflow I found to work well as an application developer is basically to
> ignore the AS side. Reasons being:
> - The framewo
Hi,
> If you are creating things from scratch:
> - only use (x,y) in Containers[2] where you do not set the Container's
> padding and you do not set margins on your elements.
I think HContainer and VContainer and % width and % height are likely to be
used more often, especialy with layout needi
Hi,
> I think we have confusion over what FlexJS is trying to deliver. If we are
> trying to make a new Flex that works on both HTML/JS and SWF platforms,
> that, to me, implies SWF is the preferred platform and we need to make
> HTML/JS platform conform to it. Thus the coordinate system needs to
How about this…
If you are migrating from Flex 4 to FlexJS, then you:
- use (x,y) to set position
- do not put margins on your elements (margins weren't in Flex anyway)
- Use PaddedContainer[1] whenever you need a Container.
- you can safely apply padding to PaddedContainer and the child elements'
I think there are a couple of things going on:
1) Some folks have asked for an API that reduces migration pain when
porting existing Flex apps.
2) We want the thinnest possible overhead over hand-coded HTML/JS/CSS.
These two goals are in opposition because Flex:
A) didn't support margins
B) had p
I agree with this. Now that these layouts and containers are really
getting used in a more practical way we can see what's going on.
I was thinking that .x and .y would be "native" setters. On SWF, .x = 0
would read x back as 0 but on JS it might read back as 20, depending on
padding and border st
I think there should be two separate value sets.
There should be set values and inferred values.
Currently FlexJS is relying WAY too much on the browser to get and set values.
Case in point: We just profiled our app and using the VerticalLayout, are
relatively simple layout was taking about 250
I think we have confusion over what FlexJS is trying to deliver. If we are
trying to make a new Flex that works on both HTML/JS and SWF platforms,
that, to me, implies SWF is the preferred platform and we need to make
HTML/JS platform conform to it. Thus the coordinate system needs to
reflect that.
Isn't this what localToGlobal etc.. did for Flex?
Personally I would like testButton.x to return 0 in all instances. Unless I
want it's actual screen position where I use the helper functions like
localToGlobal etc..
On Tue, Feb 28, 2017 at 8:50 PM, Peter Ent wrote:
> Hi,
>
> In an effort to cl
Hi,
In an effort to clean up Container and layouts, we need to look at the
coordinate system of FlexJS. Since the goal is to have the SWF side mimic the
JS side, perhaps we should visit the "coordinate system" of HTML. You'll find
an Apache Paste at [1] below. If you could run that and make any
14 matches
Mail list logo
