You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2015/05/18 19:50:12 UTC
[FlexJS] Layout Update
Hi,
I just pushed an attempt to better organize how layout works on the AS
side (The JS side heavily relies on the browser). I’ll be writing it up
in the wiki shortly.
I checked DataBindingTest, FlexJSStore, ChartExample and DataGridExample.
-Alex
Re: [FlexJS] Layout Update
Posted by Michael Schmalle <te...@gmail.com>.
Would love to check it out. :) I think I need to checkout http until this
stupid GIT stuff is figured out by Apache.
Mike
On Mon, May 18, 2015 at 1:50 PM, Alex Harui <ah...@adobe.com> wrote:
> Hi,
>
> I just pushed an attempt to better organize how layout works on the AS
> side (The JS side heavily relies on the browser). I’ll be writing it up
> in the wiki shortly.
>
> I checked DataBindingTest, FlexJSStore, ChartExample and DataGridExample.
>
> -Alex
>
>
>
Re: [FlexJS] Layout Update
Posted by Peter Ent <pe...@adobe.com>.
It should be fairly simple to have ContainerView set up the background if
explicit width AND height are set. Given what you said/wrote, this seems
to be the best fit. The problem I’ve run into is only an issue for
<js:Container width="100" height="100”/>. All other situations shouldn’t
produce an empty container space since at least one dimension is sized by
content and in that case, as soon as a child is added you see the
container.
—peter
On 5/19/15, 11:13 AM, "Alex Harui" <ah...@adobe.com> wrote:
>Interesting. We could do that, but it bugs me a bit. The deferred
>childrenAdded call is intended to close a transaction where addElement
>calls were told not to dispatch events on each call. If you look at it
>that way, a deferred childrenAdded call is an optimization option also
>available to folks just writing code in AS.
>
>If we make it a required transaction for the creation of a Container then
>in AS it means that everybody has to remember to make that call. I’d like
>to avoid that requirement if possible.
>
>If you check out the layout wiki page [1], views like ContainerView should
>be checking 3 different scenarios. For an empty container, if sized by
>the parent, ContainerView should get an event and then run its view code
>which should call the layout code (which would do nothing as there are no
>children) then call the background bead. I’m guessing the background bead
>may not pick up the right size since nobody has set the size of the
>actualParent. If so, ContainerView should be setting the size.
>
>For a container sized to content, I would argue nothing should show up, or
>maybe the size needs to factor in padding. We’d have to see what browsers
>do.
>
>For a container with set dimensions, the ContainerView should be setting
>the actualParent’s size and background bead should be drawing accordingly.
> So maybe the bug is in there some where.
>
>Of course, I could be wrong…
>-Alex
>
>
>[1] https://cwiki.apache.org/confluence/display/FLEX/FlexJS+Layout
>
>
>On 5/19/15, 7:27 AM, "Peter Ent" <pe...@adobe.com> wrote:
>
>>I¹ve been looking into this.
>>
>>In MXMLDataInterpreter.generateMXMLInstances, if the data parameter is
>>null, the function immediately returns. This means you have something
>>like
>><js:Container /> - it has no children.
>>
>>I¹m wondering if a better approach might be to re-write this function as:
>>
>>public static function generateMXMLInstances(document:Object,
>>parent:IParent, data:Array):void
>>{
>> if (data) generateMXMLArray(document, parent, data);
>>
>> // maybe we can remove this. All IContainers should be
>>IMXMLDocuments?
>> if (parent is IContainer)
>> {
>> IContainer(parent).childrenAdded();
>> }
>>}
>>
>>
>>This way, childrenAdded is called all the time. It would mean that
>>zero-or-more children were added vs one-or-more children were added. This
>>would allow things that draw backgrounds to be called in a natural way.
>>It
>>would also mean that code that is optimized to work for one-or-more
>>children should first check to see that there are children before
>>proceeding.
>>
>>That do you think?
>>
>>‹peter
>>
>>On 5/18/15, 5:11 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>
>>>
>>>
>>>On 5/18/15, 1:51 PM, "Peter Ent" <pe...@adobe.com> wrote:
>>>
>>>>The container appears to have no size. I have it explict (400x400) and
>>>>so
>>>>it should be a colored rectangle. Without content you get a blank
>>>>screen.
>>>>Add a label and you get the label inside a 400x400 colored box.
>>>
>>>Ah, ok. If the container does have size then yes, it should draw
>>>something.
>>>-Alex
>>>
>>
>
Re: [FlexJS] Layout Update
Posted by Alex Harui <ah...@adobe.com>.
Interesting. We could do that, but it bugs me a bit. The deferred
childrenAdded call is intended to close a transaction where addElement
calls were told not to dispatch events on each call. If you look at it
that way, a deferred childrenAdded call is an optimization option also
available to folks just writing code in AS.
If we make it a required transaction for the creation of a Container then
in AS it means that everybody has to remember to make that call. I’d like
to avoid that requirement if possible.
If you check out the layout wiki page [1], views like ContainerView should
be checking 3 different scenarios. For an empty container, if sized by
the parent, ContainerView should get an event and then run its view code
which should call the layout code (which would do nothing as there are no
children) then call the background bead. I’m guessing the background bead
may not pick up the right size since nobody has set the size of the
actualParent. If so, ContainerView should be setting the size.
For a container sized to content, I would argue nothing should show up, or
maybe the size needs to factor in padding. We’d have to see what browsers
do.
For a container with set dimensions, the ContainerView should be setting
the actualParent’s size and background bead should be drawing accordingly.
So maybe the bug is in there some where.
Of course, I could be wrong…
-Alex
[1] https://cwiki.apache.org/confluence/display/FLEX/FlexJS+Layout
On 5/19/15, 7:27 AM, "Peter Ent" <pe...@adobe.com> wrote:
>I¹ve been looking into this.
>
>In MXMLDataInterpreter.generateMXMLInstances, if the data parameter is
>null, the function immediately returns. This means you have something like
><js:Container /> - it has no children.
>
>I¹m wondering if a better approach might be to re-write this function as:
>
>public static function generateMXMLInstances(document:Object,
>parent:IParent, data:Array):void
>{
> if (data) generateMXMLArray(document, parent, data);
>
> // maybe we can remove this. All IContainers should be
>IMXMLDocuments?
> if (parent is IContainer)
> {
> IContainer(parent).childrenAdded();
> }
>}
>
>
>This way, childrenAdded is called all the time. It would mean that
>zero-or-more children were added vs one-or-more children were added. This
>would allow things that draw backgrounds to be called in a natural way. It
>would also mean that code that is optimized to work for one-or-more
>children should first check to see that there are children before
>proceeding.
>
>That do you think?
>
>‹peter
>
>On 5/18/15, 5:11 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>>
>>
>>On 5/18/15, 1:51 PM, "Peter Ent" <pe...@adobe.com> wrote:
>>
>>>The container appears to have no size. I have it explict (400x400) and
>>>so
>>>it should be a colored rectangle. Without content you get a blank
>>>screen.
>>>Add a label and you get the label inside a 400x400 colored box.
>>
>>Ah, ok. If the container does have size then yes, it should draw
>>something.
>>-Alex
>>
>
Re: [FlexJS] Layout Update
Posted by Peter Ent <pe...@adobe.com>.
I¹ve been looking into this.
In MXMLDataInterpreter.generateMXMLInstances, if the data parameter is
null, the function immediately returns. This means you have something like
<js:Container /> - it has no children.
I¹m wondering if a better approach might be to re-write this function as:
public static function generateMXMLInstances(document:Object,
parent:IParent, data:Array):void
{
if (data) generateMXMLArray(document, parent, data);
// maybe we can remove this. All IContainers should be IMXMLDocuments?
if (parent is IContainer)
{
IContainer(parent).childrenAdded();
}
}
This way, childrenAdded is called all the time. It would mean that
zero-or-more children were added vs one-or-more children were added. This
would allow things that draw backgrounds to be called in a natural way. It
would also mean that code that is optimized to work for one-or-more
children should first check to see that there are children before
proceeding.
That do you think?
‹peter
On 5/18/15, 5:11 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>On 5/18/15, 1:51 PM, "Peter Ent" <pe...@adobe.com> wrote:
>
>>The container appears to have no size. I have it explict (400x400) and so
>>it should be a colored rectangle. Without content you get a blank screen.
>>Add a label and you get the label inside a 400x400 colored box.
>
>Ah, ok. If the container does have size then yes, it should draw
>something.
>-Alex
>
Re: [FlexJS] Layout Update
Posted by Alex Harui <ah...@adobe.com>.
On 5/18/15, 1:51 PM, "Peter Ent" <pe...@adobe.com> wrote:
>The container appears to have no size. I have it explict (400x400) and so
>it should be a colored rectangle. Without content you get a blank screen.
>Add a label and you get the label inside a 400x400 colored box.
Ah, ok. If the container does have size then yes, it should draw
something.
-Alex
Re: [FlexJS] Layout Update
Posted by Peter Ent <pe...@adobe.com>.
The container appears to have no size. I have it explict (400x400) and so
it should be a colored rectangle. Without content you get a blank screen.
Add a label and you get the label inside a 400x400 colored box.
‹peter
On 5/18/15, 4:40 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>On 5/18/15, 1:31 PM, "Peter Ent" <pe...@adobe.com> wrote:
>
>>Encountered a couple of things:
>>
>><js:Container> with no content or explicit layout blows up; the layout
>>property is null. Maybe Container should have a default layout (Basic?).
>
>Sounds reasonable.
>
>>
>>If you use VContainer, for example, and style the container to have a
>>background color, the container will not appear unless it has content.
>>
>>You can use the new examples/RollEventsTest to reproduce these.
>
>What should show up? If no content, does the Container have size?
>
>-Alex
>
Re: [FlexJS] Layout Update
Posted by Alex Harui <ah...@adobe.com>.
On 5/18/15, 1:31 PM, "Peter Ent" <pe...@adobe.com> wrote:
>Encountered a couple of things:
>
><js:Container> with no content or explicit layout blows up; the layout
>property is null. Maybe Container should have a default layout (Basic?).
Sounds reasonable.
>
>If you use VContainer, for example, and style the container to have a
>background color, the container will not appear unless it has content.
>
>You can use the new examples/RollEventsTest to reproduce these.
What should show up? If no content, does the Container have size?
-Alex
Re: [FlexJS] Layout Update
Posted by Peter Ent <pe...@adobe.com>.
Encountered a couple of things:
<js:Container> with no content or explicit layout blows up; the layout
property is null. Maybe Container should have a default layout (Basic?).
If you use VContainer, for example, and style the container to have a
background color, the container will not appear unless it has content.
You can use the new examples/RollEventsTest to reproduce these.
‹peter
On 5/18/15, 1:50 PM, "Alex Harui" <ah...@adobe.com> wrote:
>Hi,
>
>I just pushed an attempt to better organize how layout works on the AS
>side (The JS side heavily relies on the browser). I¹ll be writing it up
>in the wiki shortly.
>
>I checked DataBindingTest, FlexJSStore, ChartExample and DataGridExample.
>
>-Alex
>
>