How to handle configs and constants?

[ffflabs]

@murrant @Spomky @CViniciusSDias @CorWatts @iquito @eisberg @zhangsean @PauluzzNL first of all, thanks for the recent contributions. I'd like to give you access to the repo, at least with triage permissions, with no obligation whatsoever, but allowing you to give me a hand with incoming issues.

Anyway, this thread is to gather opinions regarding a subject I've been struggling with.

As of now, configs affecting fonts and rendering settings are handled via global constants. It's required to declare these beforehand and , in doing so, we're polluting the global scope.

Some of these constants can be customized if users declare before loading the library config file. Some are hardcoded without a clear way to modify them. Even if they could be, these constants imply every further graph instance will be constrained to use the same config.

In the development branch I've cleaned part of the global scope pollution by using class constants, trying to move them into the classes that actually need those. While this is less harmful than the global approach, they are still preventing the customization on a per graph basis.

I tried to implement an alternative approach to retrieve configs further down the render workflow, in a backwards compatible way. This means it will use

• static variables, defined and modifiable at runtime
• environment variables when the above ones aren't defined
• class constants when the above ones aren't defined
• global constants in the last place

This works, but it's cumbersome. Also, moving constants to classes is a breaking change since you need to use a few of them when instancing or configuring graphs, plots and legends. I'm not eager to handle this just by releasing a major version, specially when it's not clear we're picking a sensible approach.

Ideally, configs should be injected from a psr container, allowing users to keep jpgraph config in the same place they keep they app configs. But this approach could be too agnostic for implementations that don't rely in psr compliant config objects.

Please post your opinion.

[ffflabs]

PD new config style can be seen in branch develop. Check the examples

[eisberg]

For backward compatibility, it may be worth providing a configuration class, passing it as an optional argument to the constructor or setOptions. Make it optional, and pass it from the parent class through the hierarchy at the time of rendering. That is, set it in JpGraph\Graph, and it will in turn pass it along the chain to the child elements.

[eisberg]

As you have noticed, ideally you should look in the direction of Di.

In addition, I would suggest an approach for creating graphs, to get away from using the Api and separate classes in the user code. Instead, create graphs using a single entry point, passing the graph configuration to it. For example, as do JS libraries such as Highcharts:

Highcharts.chart('container', {

    title: {
        text: 'Solar Employment Growth by Sector, 2010-2016'
    }, 

    yAxis: {
        title: {
            text: 'Number of Employees'
        }
    }, 

    legend: {
        layout: 'vertical',
        align: 'right',
        verticalAlign: 'middle'
    },

    plotOptions: {
        series: {
            label: {
                connectorAllowed: false
            },
            pointStart: 2010
        }
    },

    series: [{
        name: 'Installation',
        data: [43934, 52503, 57177, 69658, 97031, 119931, 137133, 154175]
    }] 

});

[ffflabs]

I was considering adding some fluent approach where you could do

(new Graph(...))
       ->withAxis(...)
       ->withPlot(...)
        ->Stroke();

In the same line that your idea: hiding as much boilerplate as possible, keeping the need to instance 12 classes to the bare minimum.

It would never quite go away, because every object you add to the graph does in turn expose another ton of methods, and they have every darned instance property with public visibility.

[murrant]

Fluent style is much easier to read indeed. When doing fluent I like to start with a static constructor like this:

public static function make(...)
{
    return new static(...);
}