haster / java-chartjs Goto Github PK

Based upon what I've gathered during the research for #18, this is what I want to do:

• This library will be java 11 based (not sure yet about further upgrade path).
• This library will be at the least usable in a jigsaw environment without breakage in the future (Automatic-Module-Name). The preferable situation would be to use module-info for all modules.

To do that, we will:

1. Update to java 9 so we can set release parameters for the compiler and check for module usage (crashdata-parent 1.22)
2. Set Automatic-Module-Name entries in manifests via maven-jar-plugin
3. Check for module-system-compliancy in dependencies. If every dependency at last declares an automatic module name, that module can go full module and create a module descriptor (module-info). If not, it will stay as is for now.
4. Update to java 11.
5. Optionally, move the nl.crashdata.chartjs.colors package in java-chartjs-data to nl.crashdata.chartjs.data.colors so all packages of the data module have the same nl.crashdata.chartjs.data prefix. This also enables us to make the module name compliant with Stephen Colebourne's recommendations
   Move the nl.crashdata.chartjs.components.* packages in java-chartjs-wicket to nl.crashdata.chartjs.wicket.components.*
6. Release all this as version 2.0.0 as these are pretty significant changes and point 5 is an API break.

(Non-test) Dependencies and modularity:

We have two locations where an objectmapper gets configured (SimpleGraphPanel and ChartJsDataTest) with the exact same settings. If users want to use the jackson-annotated classes from data but don't want to use any of the provided wicket panels, they might still want to use an objectmapper with the settings we recommend, which is hard to keep up to date.

Makes sense to have some kind of static 'getDefaultObjectMapper' method, maybe with a boolean flag for pretty print or not.

There are a number of ways to specify colors, see http://www.chartjs.org/docs/latest/general/colors.html. There should be a class, or a number of classes, so people can specify the colors and serialize it to a string without having to know too much javascript and where you can avoid the danger of javascript insertion.

Add some tests to ensure correct rendering/functioning under wicket, preferably some wicket tester things. To make sure it doesn't break when two panels are added to a page or when wicket upgrades.

It is a String now, should be a separate object which serializes to a string. Probably a few different objects to handle all the different cases, see http://www.chartjs.org/docs/latest/charts/area.html

If you use a time scale you need to be able to set a unit for the stepsize to work.

See http://www.chartjs.org/docs/latest/axes/cartesian/time.html

Wicket is only really used to provide the panel for wicket-chartjs-wicket. Most of the work in this project concerns filling the objects/data from Java and serializing to JSON. This is usable in every Java based web framework, not just Apache Wicket.

Add a set of test. Some simple serialisation tests should suffice, to ensure there is no crash for incorrectly configured builder for example.

It would probably need to be it's own module, but it might fit in the wicket-module.

It would start a simple wicket application with one or a few pages with graphs and use selenium to test these graphs a bit more. This would also enable us to test integration with front-end stuff such as the callback hooks from #20

• At the minimum, java-chartjs should be usable in a JDK 11 / JMS-using application.

• Ideally, java-chartjs would be fully java 11 built and JMS compliant. This would however probably break potential users who are still on java 8 or still not using JMS(correctly). (Do we even have such users?)

• Would going full JMS be a major or minor version bump?

• Would we want to maintain a java 8 (or at least non-JMS) branch for a while? How long?

Chartjs offers the ability to hook into callbacks upon clicking a point on the graph and such. It would be nice if you could register callbacks from the wicketpanel, especially if the callback would automatically call the serverside through Wicket ajax and you could handle the event in Java.

Upgrade to ChartJs major version 3

The readme should explain what this does, how to use it, and what to expect from each module.