HTML 5 Support

[KMCB]

I saw in another thread, it was asked about HTML5 support. This would
be of interest for my application. As part of my search for an ORM
that supports HTML5, I came across JazzRecord. Have you started any
beta support this since your June thread to gauge interest.

Are you aware of any other ORMs that support it. I tried Joose
examples, but they did not work out of the box.

Thanks,
KMCB

[Nick Carter]

Hi KMCB. Thanks for the interest in JazzRecord!

HTML5 is a tough nut to crack, as asynchronous is very different from
synchronous in terms of all the setup for potentially loading
associated records, performing validation, etc. While I do intend to
support async/HTML5, I've been busy with other projects for a bit. I
made numerous starts but ended up scrapping every one because it's a
bigger problem than I wanted to think it was initially.

I have a very simple HTML5 abstraction layer called Syncopate (http://
github.com/thynctank/Syncopate/tree/master) which I'm currently using
for a webOS project, and will probably be using it as the basis for
adding HTML5 support to JazzRecord.

The only HTML5 ORM I'm aware of is Impel: http://impel.simulacre.org/

The developer seems very responsive. I haven't dealt with it myself,
but it looks promising. There may be others but I'm unaware of them.

If you'd like to contribute by helping to add support for HTML5 while
keeping all or most of the synchronous functionality in JazzRecord,
I'd be happy for the help! The lib is under active development, rest
assured.

[KMCB]

Nick,

Thanks for your response.

I went to github. I only see a couple lines of code in storage.js.
Am I missing something.

KMCB

[Nick Carter]

I actually forgot to push the updated file, sorry for leaving the
stubs in there. Everything works now but would like to make wrapping
individual Syncopate calls in a transaction nicer to read. Using this
currently so it may see some changes over the next week or so. Feel
free to fork/modify/contribute code. May also change the core class
name from Storage to Syncopate.

[Nick Carter]

To be clear: I plan on writing some proper documentation for Syncopate
tonight or tomorrow.

[KMCB]

Nick,

Thanks, I have been playing around with it. Looking forward, to
seeing the docs.

I also have to correct my Joose statement (so not to spread FUD), I
did get them to work out of the box. I thought Firefox 3.5 had
support for the HTML5 DB. That was my bad.

Regards,
KMCB

[Nick Carter]

Yeah, I thought 3.5 would have DB support as well, it's kind of
disappointing that it doesn't.

Also of great interest to me/JazzRecord, the HTML5 DB (now called Web
Storage) folks have added synchronous support methods (I was about to
add a link to this, but discovered their spec has changed *again* and
there are no official docs on this fast-moving target available),
which would allow JazzRecord to work as-is with the addition of a new
adapter (there are currently adapters for Gears, AIR, Titanium), but
no existing browsers/runtimes which support HTML5 DB (basically all
the WebKit-derived technologies) have added the latest Web Storage
capabilities. When they do you can bet I'll be releasing an adapter!
If I have time I may write one ahead of time, because WebKit nightlies
are likely to see it before long, I'd imagine. And hope.

[Michael Gaffney]

Hey all, I've been doing some webOS programming, which is a mostly
asynchronous / event driven api. I saw a few emails in the list about
making Jazzrecord work with this type of api.

I would think, wierd as it might seem, that one could create a
continuation based version of an active record type api.

User.find(1, function(){
// update some dom api
}, JazzRecord.LOG_FAILIURE_CALLBACK);

Seems like somthing that you could do. It could get nasty though.

I would think that a standard model inspection on db init (which is
asynchronous) wouldn't be that hard through a chain of callbacks.

Just kinda talking here though.

-Mike

[Nick Carter]

As mentioned above (if you're reading this thread via the Goo Groups
site), I made several attempts at async without first planning them
through very well. All of these had to be scrapped because anything
beyond a JazzRecord.depth of 0, you have to load associated records.

You have to keep track of which associations have already been loaded,
only load to a certain depth, etc. All of these things need a concrete
tracking device, a stack or queue of some kind that will be passed
from one async call to the next, in addition to tracking the deeply-
nested object you're building that represents the base record and all
associated pre-loaded records. On top of association loading, you have
to deal with validations, some of which incur additional hits to the
database. Any db hit requires another async call, and it's just a
mess.

For the time being in my own webOS project, I'm using a simple wrapper
of the HTML5 db called Syncopate, also linked above. I'll be adding
some documentation for this shortly, but as you can see it's just a
means for calling HTML5 methods more conveniently.

Next step is to take something like Syncopate - which adds one level
of abstraction - and merge it with the ORM functionality of
JazzRecord.

Another issue not yet addressed is that automated testing of
JazzRecord currently doesn't even account for all the environments it
runs in. I've just done manual testing in AIR/Titanium, but would like
to add automated tests at some point soon. Testing anything that
depends on async is going to be a REAL pain.

Thanks for the interest in JazzRecord, Mike. I'd definitely love to
have it working across async environments (AIR also provides async db
API in addition to the synchronous one) but it's a much longer trip
than I'd initially packed for!

[Michael Gaffney]

Nick,
So does Syncopate just make the asynchronous calls into blocking or
does it have a callback mechanism?

-Mike

[Nick Carter]

While we're on the subject of problems associated with async,
migrations are going to be an ugly ugly beast. Have 20 or 30
migrations in synchronous code? No problem, a series of properties on
a migrations object has you covered.

Now need the same thing in async? Try 20 or 30 levels deep of nested
callbacks and a horror show of debugging issues. Complex async is a
nightmare. It's probably a better idea to just release migration code
custom-rolled with your async app than to rely on async migrations a
la ActiveRecord using Jazz. Incremental changes (which is what AR
migrations are, of course) are hard to do with async, but if you can
figure a way to do them all at once in parallel it's not nearly so
bad.

[Nick Carter]

It uses success/failure callbacks just like regular HTML5 calls, it
just has nicer syntax.

[KMCB]

Nick,

Unless, I miss understand your comment. Safari started support for
HTML5 DB in 3.?, I have it running in 4.X for sure (which as you
mention are based on webkit).

KMCB

[Nick Carter]

HTML5 asynchronous is supported, yes. This was originally the only
defined spec for HTML5 (now Web Storage) database API. In the last
couple months the team in charge of HTML5 also added synchronous API,
which is not supported in any browser that I'm aware.

If it's not clear what we're talking about, the synchronous processing
uses regular return statements and allows you to place one call
immediately after another making use of these returned values, whereas
asynchronous processing requires all dependent code to be executed in
a callback passed in to the async call.

[Nick Carter]

I've gone and added some initial documentation to the Github repo for
Syncopate, but be aware that as of right now the count() method is
broken, will fix in the next day or so.

Please let me know if there are any questions or concerns. I'd like to
improve clarity anywhere docs (for Syncopate or JazzRecord!) are
unclear.

[Nick Carter]

Syncopate now has support for updating across all records, select
records using arbitrary SQL comparison operators, and has full
documentation of all current features:

http://github.com/thynctank/Syncopate/tree/master