right now, it does persist to a json file as you want---it's just hidden
inside the html document, as you can see if you look at the dido.html
source. SMOP to make it load/save a _separate_ json file.
On 3/4/2010 10:21 AM, kumarachi wrote:
hi David,
indeed! i saw this announcement just after
hi David,
indeed! i saw this announcement just after posting my question and
thought that was awful weird as well...
your editable exhibit looks great, and i will try something similar
for now.
Thank you all for the ideas about a DB backend, though i would prefer
to keep it lightweight and
What I do for some of my stuff (I'm tracking server incidents in our
data center), is create my json file on the fly from a php script that
goes against a monitoring database (SQL server)...
I read all the data I need, naming the columns as I want them right in
my SQL. Then in a loop, I
Chrome is optimized for javascript processing. I believe it has a new
javascript engine the other browsers don't (yet). Makes sense that Chrome
would work well with any application heavy in javascript/json. IE seems to
have the slowest javascript engine.
- John
On Thu, Mar 4, 2010 at 11:56
Yet another option, particularly useful in our case since we have
multiple data consumers aside from Exhibit, is to store the raw data
in a relational database. In our case we store the data in MySQL but,
in theory, it could be any relational (or other) database. The
database acts as the system
Similar to Mark's case, we store much of our data in relational databases
such as MySQL, Oracle, etc This is nice because in addition to having
multiple uses/consumers of the data, we also have multiple sources/providers
of the data (mainly other staff in our group.) This allows each of us
A while ago I actually wrote an Excel macro to turn a spreadsheet into a
JSON file. This was because our implementation of Exhibit dealt with data
that I really didn't feel comfortable sending off to Babel to translate - it
was business sensitive stuff, lease dates, etc.
Anyway, I put it aside,
