flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From OmPrakash Muppirala <bigosma...@gmail.com>
Subject Re: [FlexJS] BarChart component added - render issue
Date Sat, 01 Feb 2014 00:17:26 GMT
On Fri, Jan 31, 2014 at 11:31 AM, Peter Ent <pent@adobe.com> wrote:

> Had a chat with Alex. For this particular issue, we were thinking that
> Flex's scrollPolicy should be carried over to FlexJS, but enhanced:
> scrollPolicy: on | off | auto | hidden
> which map as follows -
> on:     overflow:scroll, but scrollbars visible always
> off:    overflow:visible
> auto:   overflow:scroll, but scrollbars visible when necessary
> hidden: overflow:hidden
> or something like that. For BarChart, scrollPolicy:off would be the
> default.
> For BarChart, the real issue is that the area for the chart isn't really
> big enough. I don't think it should use a trick like overflow:visible.

You are right.  Setting overflow:visible is more of a hack.  Once we place
another visual component below the chart, it will start clipping each

> The
> size that's calculated is big enough for the series, but then the axis is
> added to that same div, forcing the scroll. I believe the area for the
> chart should shrink to account for the XAxisBead because an explicit width
> and height are set for the chart and you don't want to increase that on
> the developer.
> There are couple of things to do: add scrollPolicy and fix BarChart.

I will take a shot a fixing the BarChart rendering, if you are not already
working on it?  I am looking at the logic in BarChartLayout.changeHandler()
method.  Is that what you would do as well?


> Regards,
> Peter
> On 1/31/14 12:45 PM, "Alex Harui" <aharui@adobe.com> wrote:
> >
> >
> >On 1/31/14 7:03 AM, "Peter Ent" <pent@adobe.com> wrote:
> >
> >>Hi,
> >>
> >>First, I can confirm that Om's suggestion of *adding* the createElement
> >>override to the cross-compiled/generated BarChart.js does fix the
> >>problem.
> >>
> >>Secondly - how do we make it possible to allow customization of the
> >>JavaScript that gets cross-compiled? This is bound to be necessary and
> >>clearly solves this problem.
> >Well, the current rule is that if you need custom JS, then that class is
> >not available for cross-compilation and needs its own parallel JS file in
> >the repo.
> >
> >>
> >>A bunch of things popped into my head:
> >>
> >>1. We add createElement to UIBase.as so there is parity with the
> >>JavaScript code. We might actually make good use of this on the AS side,
> >>but I haven't given that any thought. Having it though, would allow the
> >>AS
> >>BarChart to override the method and introduce AS code that would get
> >>cross-compiled into JavaScript.
> >We could do that, but it would mess up code coverage tooling.  We could
> >add compiler directive so certain code isn't seen by the code coverage
> >tooling or even allow JS instead of AS inside comments in the AS file that
> >get output to the JS file as well.  But either way, at some point, someone
> >may have to create a parallel JS file.  These various ideas just reduce
> >the probability.
> >>
> >>2. We need to be able to programmatically set style properties that get
> >>cross-compiled correctly. The key to the BarChart issue is
> >>"this.element.style.overflow = 'visible';" or setting the overflow style
> >>to "visible". Perhaps something like:  this.style = "overflow"; on the
> >>ActionScript side would coax the compiler to generate the
> >>"this.element.style.overflow = 'visible';" on the JavaScript side.
> >That's what the CSS file and media query is for.
> >>
> >>3. Allow JavaScript-specific code to be placed in the ActionScript code,
> >>maybe using metadata:
> >>
> >>override public function createElement()
> >>{
> >>[JavaScript]
> >>  this.element = document.createElement('div');
> >>  this.element.style.overflow = 'visible';
> >>  this.positioner = this.element;
> >>[JavaScript]
> >>[ActionScript]
> >>   // code within these [ActionScript] tags does not get cross-compiled
> >>[ActionScript]
> >>}
> >And an option 4 is to examine the lifecycle in both AS and JS and try to
> >make them more similar.  The problem is that on the AS side, the
> >components are the display elements but on the JS side they wrap the
> >display elements.
> >
> >>
> >>We really do need to have some way to tweak the JavaScript code, whether
> >>it be styling or something else.
> >Well, it would reduce the number of parallel JS files, but really, we
> >don't have to have a way to tweak the JS code from the AS side.  I'd like
> >to see if this case can be solved by modifying the CSS file.  Then we'll
> >see how often we hit the need to do this sort of thing again and decide
> >what to do.
> >
> >-Alex
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message