CSS vs API Property Settings...

[FP2006]

We currently leverage CSS as a way to set default properties for our charts.  We then want to override the defaults (i.e. colors) that are linked to a value in the data we are showing.

 It is my understanding that the CSS is applied after the API, so that if we use CSS we can not override the values via the API.

 

Is my understanding correct?  If so, is there anyway to override that so we can use the API to override defaults in the CSS? 

[JuanC]

>> It is my understanding that the CSS is applied after the API, so that if we use CSS we can not override the values via the API.

What really happens is that when we see that you included the jChartFX CSS we do not generate visual attributes for most of the graphic objects, instead we assign one (or more) classes so that the CSS styles can be applied.

If you want to have for example a bar chart where bars bigger than a certain value are displayed differently you could use ConditionalAttributes as follows

    chart1.setDataSource([30,40,35,50,55,48,32]);

    chart1.setGallery(cfx.Gallery.Bar);

    

    var condAttrs = chart1.getConditionalAttributes();

    var conditional = new cfx.ConditionalAttributes();

    var condition = conditional.getCondition();

    condition.setFrom(49);

    condition.setTo(80);

    conditional.setTag("SpecialPoint");

    condAttrs.add(conditional);    

This will work as long you have a SpecialPoint class in CSS, e.g.

.jchartfx .SpecialPoint {

fill: #D0A000;

stroke: #806000;

}

Obviously another possibility would be to NOT include the CSS which will give you complete control over the colors/etc using the API. 

JuanC 

[FP2006]

Another question on the CSS vs API issue.

 

Is it all or nothing?  Meaning if I do not have certain objects controlled in the CSS (i.e. series colors) can I use API to set those and CSS to set the other object/attributes?  Or once I use CSS in any way the API is out of the picture?

 

I think the chart has defaults that are embedded in the JS code.  Is there anywhere we can see those?  I am wondering of the defaults we are setting via CSS are similar to the defaults you have coded in the control.  If that is true, then exclusing the CSS would be less painful.  Although we would be walking away from giving users the ability to skin the charts to match their business situation. 

 

Has anyone requested a flag that determines this behavior.  It seems to me that setting general defaults in CSS and applying those to the visual attributes and then overriding as needed in API would be the most flexible model.

 

Appreciate the help!  

[JuanC]

>>Is it all or nothing?  ...  Or once I use CSS in any way the API is out of the picture? 

Currently CSS vs API is an all or nothing mode. Early on the painting code we decide whether you included a CSS or not and there are several places in the code where this mode is used to decide whether we should generate an SVG object with brush,stroke,etc. or if we should generate class="xyz"

So unfortunately yes, once you use CSS the API to change colors, stroke thickness, etc. is out of the picture. 

>> I think the chart has defaults that are embedded in the JS code.  Is there anywhere we can see those? 

The chart has defaults embedded in the JS code and they are almost identical to the "default" CSS. I had to write a small app to "descramble" our default palette but I think these are the colors we are currently using, the first 2 lines are the fill colors for the first 16 data series (we darken the color a little bit to get the border colors)

#57ACDA, #93E24E, #F26C5B, #F5D34A, #F89553, #65C773, #5ABEC7, #CE9884

#5F6775, #E9EA52, #E04E61, #6FE4C8, #ECA63F, #99D0A0, #CE8FBE, #8DC3E0

Background #F5F5EE

Alternate Background #F5F5EE

Plot Area #00FFFFFF

Border #DBDBD9

Axes and Gridlines #DBDBD9

Axes Alternate #F5F5EE

Constant Lines #FC4B35

Stripes #FFFFFF

Labels #666666

Point Labels #666666

Marker Border #00FFFFFF

Titles #0296B1

Titles Back #00FFFFFF

LegendText #666666

LegendBackground #00FFFFFF

Data Background #F5F5F2

DataForeground #666666

DataAlternateBack #FFFFFF

DataAlternateFore #000000

DataTitlesBack #DDE3E7

DataTitlesFore #6D7D8A

DataGridlines #DEDAD3

DataBackground #F5F5EE

>> Although we would be walking away from giving users the ability to skin the charts to match their business situation. 

Can you expand on this? Giving users ability to skin the charts could mean giving the users ability to choose a CSS that you ultimately include in the page (assuming this is a server-side scenario).

One thing we will be supporting in future builds is to change the default palette of the chart by declaring an array of colors in the JS, this code is part of the new release we are planning that includes maps and gauges so we do not have a firm release date yet but if this sounds like it could help you we could set you up with pre-release bits. 

>> Has anyone requested a flag that determines this behavior.  

Not really but it would be hard, internally our code is really API based, so we are always painting all elements with colors, widths, etc that are controlled by the API but obviously we have to have a default in case you never set those colors, this means it is not really easy for us to differentiate between a color/thickness that is there because it is default or a color/thickness you set with the API so we would have to set flags whenever you set a property to convert that "object" into API based, also sometimes there are several cluster of properties that affect related items, e.g. point labels for a particular series, so if you change the color for the point labels for series 2, does that means you are also changing series 2 to be API-based?

It is certainly not impossible and it would be more flexible but it would add a level of complexity to the code. There might be alternate approaches for example what about a flag that turn off CSS for all series in the chart, please try to include (if possible) more information about your scenario.

Regards, 

JuanC