|
|
DesignGoals
Goals for the project and discussion of implementation choices.
Introduction
The Data Pages Extension's main purpose is to allow often changing, semi-structured external data to be integrated with a constant and consistent format into a Content Management System.
The reasons for this are:
- Data changes often. Its structure and presentation changes less often.
- Changing data values by hand is error-prone and tedious.
Implementation Details
HTTP GETs
Why is that data retrieved through HTTP? If it lives on my machine, wouldn't it be more efficient to just look it up?
Sure it would, but HTTP GETs are more RESTful, right? ;)
Well, that is one of the reasons, but the main one is that I wanted to be able to pull from external stores and the combination of Ruby's open-uri and json libraries made that too ridiculously easy to even contemplate anything else.
Future versions may include some kind of pluggable retrieval method, but I haven't given much thought to it yet.
Another major reason was that it gives the option of serving the data from a live application or freezing some data into a static file and just serving it from a directory somewhere. Very convenient if you have some kind of data that gets published and researched in cycles.
Yet a third reason is that you can proxy requests to through another script (and doesn't even have to be Ruby) to make any kind of changes you want to the data before templating it.
Ok, 4th: cacheability. If you're using something external, you can use a cache-server to serve the data locally.
JSON
Why is JSON the only data format?
JSON is nice and simple with great Ruby bindings. For my purposes, the only complex data (i.e. data the couldn't simply be coerced into a String) I wanted was Hash and Array. Hash is handled by specifying "key" attributes in the "value" tags. Arrays are handled using the "values" tag.
YAML was another choice and might be supported in the future. The only reason I chose JSON over YAML was that it left the door open to do some Ajaxy kinds of things with the data store.
Minimal data manipulation in the template language
You'll notice that there are relatively few options for manipulating the data. You can't add numbers, you can't drop into straight Ruby, the tags aren't Turing complete, you can't even select particular indexes from arrays and ignore the rest (although that might change...). The idea is to keep things minimal so that there's no question about where certain data operations should be -- they should always be at the source. Also, fewer tags means pages are less imposing to edit for the code unsavy among us.
This may present a few problems for people using truly external data. Sometimes these mean old mashup-able applications just don't give us stuff in the format we need! My suggestion is to use an external script or application to proxy (and even cache) calls to the external service and do any kind of cleanup, culling of unnecessary row members, etc. If you want to stay all-Ruby, try making an a tiny Camping application to do this. Or even a Mongrel handler.
Either way, take this word of warning: Do not serve your data from the same process that Radiant is running on! At best you'll be down a mongrel process (assuming you're clustering). At worst you'll get in a deadlock as the templating request waits for the data request to return, which is in turn waiting for the templating request to finish up before it can do anything.
Some data formating
In my book data formating is different than data manipulation. This is why we have tags like <r:currency>, <r:precision>, and <r:delimiter>. Sometimes you might want to template the same data in a different way depending on the page. That's reusability of content for ya!
Mercurial
What's with Mercurial?
Tastes my vary, but I really like Mercurial. Sure it's written by a bunch of no-good Python programmers with their PEPs, and their white-space, and lambdas instead of blocks, and their world-wide conspiracy to have only one way of doing things...
Whoops -- sorry there. What was I saying? Oh yes, Mercurial. Turns out they can write a marvelous distributed version control system. (and just kidding about the no-good part ;) ). And even though I'm just one guy, I like the ease-of-branching that it gives me and overall light-weight feeling.
So SVN is going to be a dump of the Mercurial repository which I'll maintain for ease of deployment.
And if Google Code could please offer Mercurial hosting I'd be as happy as a little girl.
Sign in to add a comment