Zig Ziglar once said:
“People often say that motivation doesn’t last. Well, neither does bathing - that’s why we recommend it daily.”

My daily dose was Graeme’s nod on his blog yesterday. In wrapping up the last few remaining issues, I am happy to announce that the Grails Google Chart plugin now fully implements Google’s spec. New in this release is:

• line styles
• grid lines
• shape markers, and
• range fill

The one breaking change is that the attribute "shapes" has changed to shapeRangeFill because those features use the same attribute key on Google’s side.

It has come across my mind more than once to abstract a chart into a domain object so that it can be stored. For the needs of most Google’s 50K threshold is perfectly fine. The one area that might cause issues is if there are many charts using the extended dataset being parsed at the same time. If the data changes infrequently, it’s better to store the data string than regenerate. Additionally, a domain object could allow the user to use nicer color names.

Thoughts? Objections? Concerns?

Comments

1. Andrew Perepelytsya said:
   I don't know if you've seen this one: http://zanthrash.blogspot.com/2008/01/groovy-chart-builder.html Would be a perfect match, IMO.
2. JW said:
   Andrew, I did see it. For Grails, I'm not confident that a builder is the best approach. It doesn't exactly mesh well in the context of a page tag. If a builder were to be, it should generate a self-aware object that could be stored in the database and that could create its own chart string.
3. Zan Thrash said:
   Hey James, Thanks for checking out my code. I originally wrote the builder to scratch and itch I had while doing some Groovy work only thinking of Grails as a side thought. I guess I was thinking that you could create the chart URL via the builder in a controller or domain object and then pass the output as a param to the view. I do like your notion of creating an object that can be store in the DB. Maybe we could combine or forces.