On Mon, Feb 3, 2014 at 6:37 AM, Peter Ent <p...@adobe.com> wrote:
> 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
>
>
Just checked in a fix. Please take a look.
App works fine even though I am getting a warning during the JS compilation
part:
WARNING - Bad type annotation. Unknown type
org.apache.flex.charts.beads.layouts.BarChartLayout
[java] var /** @type
{org.apache.flex.charts.beads.layouts.BarChartLayout} */ barChartLayout =
org.apache.flex.utils.Language.as(this._strand.getBeadByType(org.apache.flex.core.IBeadLayout),
org.apache.flex.charts.beads.layouts.BarChartLayout);
What am I doing wrong?
Thanks,
Om
> 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
> >> >
> >>
> >>
>
>
