Hi Om,
Sorry for the delayed response. BarChartLayout.changeHandler is the place.
You might need to look at the BarChartView bead as well.
Thanks so much!
Peter
On 1/31/14 7:17 PM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote:
>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
>> >
>>
>>
