I like that you are attempting to mimick ActiveRecord::Base in JavaScript, it sounds interesting and useful; I’ll have a look at your code at some point…

“One final point about style – from your examples you seem to usually downcase everything except the last part of the class name…”

My convention is certainly not universal. I try to follow these primary conventions for code that is written in what Douglas Crockford calls “Pseudo classical” style (i.e., how JavaScript is usually written):

1. Package-objects are always lowercase (a package object is what is created by the namespace function).
2. Constructor functions and singleton objects start with upper case.
3. Utility functions are lowercase.

I haven’t checked this, but I believe that Ext is actually consistent in its naming conventions: Ext is a singleton object (which lives in the global namespace) ✓ Ext.data plays the role of a package object so it is not capitalized ✓ Ext.data.Record is a constructor function ✓

I think the only other rule that governs this is: if the object/function consists of two words then each word is uppercase, e.g., ColorPalette.

“Thanks for maintaining a great blog!”

Thanks for that comment! Great to get some interaction, so keep commenting

/Karl

Thanks for that. MVC.model.Base is somewhat akin to ActiveRecord::Base – you just tell it what your model is called and what fields to include and from that it knows how to map each model to a URL resource, how to pluralize/inflect (in most instances anyway), as well as providing convenient Stores for both an individual model (e.g. /my_resource/1.json) or a collection (/my_resource.json).

Model was one of the first classes I wrote and is in need of some major refactoring – I’m just trying to figure out the best way at the moment. I like the approach you take in your post about extending Ext.data.Record – I think I’ll give it a go that way. I’m really trying to achieve a Rails-like model definition so I’ll see how far that goes…

The code is on Github at http://github.com/edspencer/ext-mvc/tree/master/model/base.js if you’re interested. Model.Base is not pretty (yet) but some of the other bits are!

One final point about style – from your examples you seem to usually downcase everything except the last part of the class name (e.g. com.trifork.tribook.model.Reservation). ExtJs seems to be quite random though – e.g. Ext.data.Record, Ext.form.Action.Load, Ext.ColorPalette all seem to follow a different convention. ‘Ext’ is always capitalized, the next segment is usually not (except for some classes like Ext.Ajax and Ext.ColorPalette), then the third segment is usually capitalized again. Do you know of a ‘universal’ convention for this? Why not just capitalize everything?

Thanks for maintaining a great blog!

Ed

Ah, yes I see the problem. I’m not sure how your MVC.model.Base works; however, if you were just using regular models (i.e. models created by Ext.Record.create), then I think you could get around this using inheritance.

The strategy could be: code-generate the base model using the approach above (or your own adapted version), then create a model which extends the base. If you put all your extra logic in the extended class then you can safely regenerate the base class when your migration changes — the base would be overridden, but the extending model would remain the same.

Incidentally, you could use the code I posted on extending models created by Ext.Record.create in this blog posting.

Think that would work out for you?

/Karl

AdFunded.models.AdvertisingCategory = new Ext.ux.MVC.model.Base(‘advertising_category’, {
fields: [
{ name: 'id', type: 'int'},
{ name: 'name', type: 'string'},
{ name: 'description', type: 'string'}
],
controller_name: ‘AdvertisingCategoriesController’,
human_plural_name: ‘Advertising Categories’,
url_name: ‘advertising_categories’
});

There’s a bit of magic going on under the covers here but essentially the model creates an Ext.data.Record with the fields you pass it in the background. Trouble is – to regenerate this would lose the additional config options I’ve given the model (and some models have much more inside them than this one).

To counter this I have been writing a Schema library for Ext MVC, which converts Rails migrations (or potentially any other kind) into a JS form and runs them in sequence at run time. That would mean an end to specifying the fields in the model, which makes migration easier, but it’s also nice to have them there in the model file (like with the rails annotated models plugin).

I’m still not sure what the best way to go on that one is – any ideas?