On Fri, Jan 31, 2014 at 11:31 AM, Peter Ent <p...@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
other.
> 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?
Thanks,
Om
>
> Regards,
> Peter
>
> On 1/31/14 12:45 PM, "Alex Harui" <aha...@adobe.com> wrote:
>
> >
> >
> >On 1/31/14 7:03 AM, "Peter Ent" <p...@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
> >
>
>
