Not only xml!

Question

I would be really helpfull to access access data with spry
without using xml!
Is it planned to add such a functionallity?

Answer 1

Hi Andy,
Well first off, when you think of JSON, you should think that
it is just a compact way to store a
representation of a dictionary / hashtable / associative
array / object, arrays, strings, numbers, and booleans. I wouldn't
really say there is such a think as a 'JSON object'. JSON is just
about the way to represent information and pass it around. There
are a number of libaries to convert a tree of data in PHP (and
other languages) to JSON, check out this page:
http://www.json.org/
So as far as how to store your data in the database, JSON
should be the furthest thing from your mind. Setup your database as
you normally would, fetch data from it, manipulate it, and then at
the last step, shove it through a JSON serializer to send it out to
the client.
As for your application, here is an approach you might want
to consider. I saw this at NFL with their content management
system, and I'm sure it's used in lots of places, but at the time
it was a really cool new idea to me.
They stored all their data in a database, for pages that were
very dynamic to pages that were very static.
Next, they created a command line utility that given a URL
would fetch the data from the database, and write out a HTML file
to the correct location on disk. So say, you wanted to create the
page
http://www.nfl.com/pugbowling/index.html,
you'd just pass it that URL, it'd go find the data, generate a
page, and write it out to the docroot folder. In this way, they
could use the database to store all their information, and their
whole site could be dynamically generated from the database.
Then, and this was the cool part, they added an entry to make
their 404 error handler be the above script. So say, I come in and
want the pugbowling page above, but it hasn't been generated. A 404
error gets triggered, that triggers my page generation utility, the
page gets written to disk, and then that page gets returned!
Saweet!
Finally, when you edited the data in the database, it would
trigger a deletion of the page(s) that went along with that data,
so that the next user would trigger the 404 and get back the new
page. I think they also had something that would kill off files
that were really old and hadn't been accessed in awhile, just to
save space (imagine how much space NFL would waste if it kept a
copy of every news story around in full HTML form on disk?)
Anyways, the same idea could apply to creating actual XML /
JSON files. Let some process handle the creation of the files for
your, making that part of the process completely automatic, so you
just need to handle putting data into the database.
It all would depend on the amount of data, the complexity of
it, and such as to how much you want to implement something like
above. For example, I maintain some websites using XML + XSLT and
just use ANT to generate the site. If I had a lot more data, I'd
probably go with more of the approach above. Or maybe half of
above.
Good luck!
-doug