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. 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.
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
>
