Enable persistent, reusable sparklines

This is an interesting idea, being able to call the same data forward when needed. My only thought would be to allow users to define sparkline data through a configure form and give it a named shortcut (e.g. they enter the data and the shortcut is set to 'baseball'). Retaining a GUI (albeit a form) would probably help non-power-users out a lot. Then, there's also no worries about arbitrary code execution through Sparkline.

I realize I'm kind of changing the idea of this a little, but it'd still function the same way, just a different way to storing/pulling data. So the tag would either be [sparkline bar 1,2,3,4,5] or [sparkline baseball] (or something to that effect).

Any other thoughts?

I like the idea of mapping name to URL through the admin interface much better than embedding the URL in content.

Mathfilter has the embedding functionality:

http://www.universalpantograph.com/equations-using-tex

but not the naming idea.

Although I wish there was some sort of standard for these proliferating microformats in Drupal. They are all great, but we soon clashes will begin as the namespace gets more and more crowded....

I'm definitely interested in making sparkline allow the same sparkline to appear in more than one place. I think that's a matter of getting the right API and persistence model.

I don't know that I'd consider allowing arbitrary PHP to be called. That's like providing an author with the PHP input format capability, which gives one all the rope necessary to hang oneself, crash the site, or create a huge security problem.

I see your point on the PHP. With the TeX model there isn't a general purpose engine, so the security issues aren't as great.

Could the PHP be compiled? Could a JavaScript library be used?

Possibly the microformat data itself could be stored -- but that seems awfully limiting.

Could the PHP be compiled? Could a JavaScript library be used?

I didn't quite follow the direction of these questions. Are we talking about simply reflecting what the Sparkline filter currently does but in a multi-use way, or opening up the Sparkline library's interface to be more usable via the module?

If it's the former, then compiled PHP or JavaScript, I believe, would be over-kill. It's only data that's being worked with, and shifting the data to code seems needless to me. The data simply needs a method to be stored and retrieved.

If it's the latter, then it's a matter of how to resolve cached Sparklines that have been created elsewhere (in-code or via a GUI?). Additionally, it's adopting the proper interface for exposing the Sparkline library's functionality, which seems to be a little out-of-scope of this module to me (at this point, anyway).

Or am I missing the mark here?

I would love to implement dynamically created sparklines on my site. PHP seems to be the way to do this, but as a novice programmer it is not at all clear to me how I'd accomplish it. An interface that walked me through the creation of each dynamic sparkline would be terrific. If that's not possible, step-by-step instructions on how to insert php into a sparkline tag, along with accompanying examples, would be welcome.

Retitled to fit the feature request I'm willing to implement. A module developer or someone with node PHP access can already call the sparkline routines directly, if so desired. I'm not interested in providing some other sort of PHP access, due to all of the security and implementation considerations. However, the ability to reuse the same sparkline in multiple places is a good idea.

Great! That's really my requirement. It's re-usability that I want.

Isn't a simple method of storing cached files the way forward? Imagecache has been doing this successfully for quite some time now. Multiple references to the same image all render the same "thumbnails" for example.

Then you could simply store the sparkline files at (eg) /sites/<default>/files/sparklines - right?

It's up to the implementor, of course, but for myself, I'd always rather separate the concerns of data and rendition and render on the fly. What if I'm generating the sparkline dynamically? Then I have to manage the files directory too...

... render on the fly.

I agree.

So, if 50,000 (edit: site-registered) people hit your new article which contains a sparkline, you don't want that cached and delivered from a static source or a content delivery network??

I think you probably do!

meh. good point.

Won't the cache layer handle this? And then clear if the sparkline is updated?

I was reacting to what I thought was a proposal to store the rendered sparkline on the file system.

You can't just create an image on the fly and expect it to exist in cache somewhere! If the image is dynamically generated, even with the same name the browser cache will deem the image out of date and force recreation of the image every page load.

In order for any kind of performance increase, the image needs to be written to disk. Then the Drupal caching mechanism can churn out these images as part of a cached page. Other than that, the only way to speed things up is to use css sprites or a content delivery network, both of which aren't really relevant to this kind of use case unless the cache age can be quite high.

There is some generated sparkline image file caching already going on in the current code, by the way.

I'm open to patches to implement these suggested features.

I'm not currently working on any sparkline projects, so probably won't spend much time on this module until I need to use it again.