
Impel - HTML5 Javascript ORM - tortilla
http://impel.simulacre.org/
======
mmastrac
I'm always wary of third-party libraries that have their own license:
<http://impel.simulacre.org/crm/license>

It's probably not an issue, but if I were to use it, I'd have to spend time
parsing this license to make sure that I _could_ use it.

To third-party library authors: please, pretty please choose a well-known
open-source license for your project. If you are trying to turn it into a
commercial venture, you can still do this with a well-known license (see
MongoDB's license for an example:
<http://www.mongodb.org/display/DOCS/Licensing>).

------
dandelion
Is it really necessary to add a library dependency like Mootools into a JS
ORM?

------
chrislloyd
This is a pretty good example of how _not_ to write Javascript.

~~~
biafra
Can you give some examples?

I am new to JS and would like to know what to avoid.

~~~
chrislloyd
Learn about prototypical inheritance and Javascript's lack of types.

Everything in Javascript is an object. By object I mean a hash table (or
dictionary, if you are coming from Python). Even functions and arrays are
objects! Put that in your pipe and smoke it. Have a look at this code:

    
    
        function FancyArray() {} // In this setting a function is just a fancy name for an object.
        FancyArray.prototype = Array.prototype;
        var my_new_fancy_array = new FancyArray();
    
        my_new_fancy_array[0] = 'foo';
        my_new_fancy_array.length = 1;
    

Remember that the square brackets and the dot notation are equivalent. This is
very important. The last lines could be written like:

    
    
        my_new_fancy_array['0'] = 'foo';
        my_new_fancy_array['length'] = 1;
    

Anyway, this will return you a psuedo Array => ['foo'] (This is the basis of
how jQuery works). Going back to the first couple of lines, we made a new
object, FancyArray, then set its prototype to the prototype of Array (so we
get all the nice methods like toString and push etc.). We then created a new
FancyArray.

I'm going to cut this tutorial short because I have somewhere to be, but a
good source of good Javascript is Douglas Crockford and his bite-sized book
"Javascript the Good Parts" (and a good post of prototypical inheritance here
<http://javascript.crockford.com/prototypal.html>). If you are willing to take
a certain level of Russian crazy have a read of Dmitry's blog
<http://dmitry.baranovskiy.com/> (he wrote Raphaël). He gets it.

Back to Impel, the heavily OO code and the way things are named are a bit of a
tell tale sign. The author is probably a Java or PHP programmer who has spent
the night getting tipsy in this weird and wonderful gay bar and, hitting on
the only chick around, hasn't checked the goods before he moved in for a kiss.
Javascript is a beautiful language when you get to know it and accept that
it's different from anything you've experienced before.

~~~
simulacre
Yup, it's based heavily on PHP's Propel <http://propel.phpdb.org/>.

I built it that way so that I could quickly port a PHP webapp backend into
Javascript for use in a self-contained HTML5 version of the entire webapp.

If you want a straight JS ORM that takes into account JS's prototypical
inheritance, and loose type system then Impel is not for you.

Regarding the license, it's basically the MIT license. Yes, you can use it.
Yes, you can modify it. Yes, you can sell it. Just give a little bit of link
love back.

------
endlessvoid94
I had this idea about a year and a half ago, and I decided:

1 - To do this in Javascript would require a MASSIVE amount of code 2 - It
required too much custom setup on the server, and 3 - It solved a problem that
didn't exist.

I still think #3 is the most relevant, but #1 and #2 are still big
impediments. From what I can see, this library doesn't address any of those
concerns.

Perhaps it will do well, though. I can't wait to see. Good work and good luck!

------
JimBastard
32k packed is pretty fucking big for a JS ORM.....

~~~
mmastrac
It would probably be a lot smaller with a packer that obfuscates field names
too (ie: Closure Compiler).

He could probably get it down further by stripping all of these exception
strings from the release version and replacing them with structured types and
numeric codes. Some of these are really development-time assertions that
shouldn't be in the release code anyways:

throw ("doSelectJoinAllExcept requires an array of peer names as an argument")

~~~
JimBastard
I'm pretty sure I could write a better JS ORM in less then 10k unpacked (no
comments / docs).

