OR-Mapper for the HTML5 database and the Google Gears database

[Malte Ubl]

Hey,

maybe this is interesting to Gears users:
I implemented a (still rather proof-of-concept)
object-relational-mapper that works with both HTML5 and Google Gears
database backends without any changes to the front end code:
http://joose-js.blogspot.com/2008/08/or-mapper-for-html5-database-and-google.html

Cheers
Malte

[Ben Lisbakken]

Malte that's great!

[Malte Ubl]

Hey,

just some updates that make the tool actually useful:

- There is now a remove method in every entity to delete it from the database
- Transaction support for Gears. Transactions are queued, so you can
safely nest them in callbacks but they wont be executed until the
current transaction is done (same behavior as with HTML5 databases)
- A little meta class magic to make Entity definitions even nicer:
This is how entity definitions look now:

Class("Person", {
isa: ORM.Entity,

tableName: "person",

hasOne: {
mother: {
isa: function () { return m.Person }
}
},

hasMany: {
cars: {
isa: function () { return m.Car },
foreignKey: "owner"
}
}
});

If you are interested in how these DSL like class definitions are
achieved using the Joose framework, this commit might be interesting:
http://code.google.com/p/joose-js/source/detail?r=154

Bye
Malte

--
SCHAFFHAUSEN COMMUNICATION GROUP
Schaffhausen ITC Solutions GmbH / Daimlerstraße 17 / 25337 Elmshorn

Fon +49 41 21.47 29-459 / Fax +49 41 21.47 29-455
u...@schaffhausen.de / www.schaffhausen.de

[Malte Ubl]

Hi,

yet another "note".

To make this topic a little more plastic I converted the original
sticky notes example
http://webkit.org/misc/DatabaseExample.html

to use the new OR-Mapper:
http://joose-js.googlecode.com/svn/trunk/examples/simple_orm_sticky_notes.html

This is a one-to-one conversion, so the code is a little ugly and uses
a lot of webkit specific features. Thus the example looks a little
nicer with webkit and probably doesn't run in all browsers that
support gears. I tested with FF3.

Bye
Malte

[Ben Lisbakken]

I was having a bug with it -- when typing the cursor keeps going back to the start of the line.  Also, the text jumps out of the note div.

-Ben

[Malte Ubl]

Hey Ben,

I know about the bug. If you have a smart idea how to quickly fix it
that would be great.
The original example manipulates the DOM directly and will probably
run into all kinds of issues in different browsers. To make it more
robust I'll probably have to rewrite it using jQuery or another
library.

For now you'll have to type very fast to enter correct text :)

Malte

[Malte Ubl]

Hey,

I moved the example to jQuery and implemented an automatic databinding
system that binds objects on the screen to objects in the database:
http://joose-js.googlecode.com/svn/trunk/examples/simple_orm_sticky_notes.html

If you are interested, here is the source:
http://code.google.com/p/joose-js/source/browse/trunk/examples/sticky_notes.js#20

There is only a single class, which defines its bindings to a jQuery
object in the bind: {} clause.
Changes to the database objects state is automatically propagated to
the jQuery object and vice-versa.

Bye
Malte

[Malte Ubl]

Hi All,

some more updates on the OR-Mapper:

I implemented a couple shortcuts that enable working with datasets in
a jQuery style.

As an example, the sticky note code had a couple lines that looked like this:

Note.selectAll(function (notes) {
notes..each(function (note) {
note.redraw()
note.show()
})
})

The API is inherently asynchronous because that is the only way that
is provided by the HTML5 database API.

This can now be written as:
Note.selectAll().draw().redraw().show()

This is pretty dark JavaScript magic going on, because all methods
after selectAll won't really be executed until the select has actually
been executed.
I like this API style much better, but it has some serious draw backs:
- In the Gears version you loose the transaction context because evil
global vars are involved (in my mock up impl. of the HTML5 api)
- If there is something coming in the next line, one would expect it
to be executed after show() which is not the case.

Does anybody have an opinion whether I should keep the new API?

Bye
Malte