Friday, May 25, 2012

Rules for HasOne and BelongsTo Associations in ExtJS

  1. Put the proxy in the model, unless you have a very good reason not to [1]
  2. Always use fully qualified model name
  3. Always set the getterName
  4. Always set the setterName
  5. Always set the associationKey, if the foreign object is returned in the same response as this object
  6. Always set the foreignKey, if you want to load the foreign object at will
  7. Consider changing the instanceName to something shorter
  8. The getter behaves differently depending on whether the foreign object is loaded or not. If it's loaded, the foreign object is returned. Otherwise, you need to pass in a callback to get it.
  9. You should set the name property if you plan to override this association.
  10. You do not need a belongsTo relationship for a hasMany to work
  11. Set the primaryKey property if the id field of the parent model is not "id"
  12. Sometimes you need to use uses or requires for the belongsTo association. Watch out for circular references though.
  13. Calling setter() function does not seem to set the instance. Set object.belongsToInstance = obj  if calling the setter().

Ext.define('Assoc.model.PhoneNumber', {




 * Assuming Contact model uses an AJAX proxy with url 'contacts', and its id field is "id", 
 * the below function call will make an http request like this:
 * /contacts?id=88

var pn = new Assoc.model.PhoneNumber( { contact_id:88 } );

pn.getContact( function(contact, operation){ 
  console.log('tried to load contact. is now set to the contact');
} );

/* you can call phoneNumber.setContact(contact). This will set contact_id on the phone number, BUT it won't set the contact instance on phonenumber, which is likely a bug: */

var contact = new Assoc.model.Contact({id:77});

var phoneNumber = new Assoc.model.PhoneNumber();


console.log(phoneNumber.get('contact_id')) //77

console.log( //undefined = contact; //you need to do this if you want to use that reference in the future.

[1] The store will inherit its model's proxy, and you can always override it if necessary

Rules for HasMany Associations in ExtJS

  1. Always put your Proxies in your Models, not your Stores, unless you have a very good reason not to *
  2. Always require your child models if using them in hasMany relationships. ** 
  3. Always use foreignKey if you want to load the children at will
  4. Always use associationKey if you return the children in the same response as the parent
  5. You can use both foreignKey and associationKey if you like
  6. Always name your hasMany relationships
  7. Always use fully qualified model names in your hasMany relationship
  8. Consider giving the reader root a meaningful name (other than "data")
  9. The child model does not need a belongsTo relationship for the hasMany to work

Ext.define('Assoc.model.Contact', {


        'Assoc.model.PhoneNumber'          /* rule 2 */

        'name'                             /* id field is inherited from */

        foreignKey: 'contact_id',          /* rule 3, 5 */
        associationKey: 'phoneNumbers',    /* rule 4, 5 */
        name: 'phoneNumbers',              /* rule 6 */
        model: 'Assoc.model.PhoneNumber'   /* rule 7 */

    proxy:{                                /* rule 1 */
        type: 'ajax',
        url: 'assoc/data/contacts.json',
        reader: {
            type: 'json',
            root: 'contacts'               /* rule 8 */

// example usage:

var c = new Assoc.model.Contact({id:99});

 * assuming that PhoneNumber.proxy is AJAX and has a url set to 'phonenumbers', the below function would make an http request like this:
 * /phonenumbers?page=1&start=0&limit=25&filter=[{"property":"contact_id","value":"99"}]
 * ie, it would make a request for all phone numbers, but ask the server to filter them by the contact_id of the Contact, which is 99 in this case

* The store will inherit its model's proxy, and you can always override it
** To make it easy, and avoid potential circular references, you can require them in app.js .

Saturday, May 19, 2012

ExtJS History is backwards

Ext JS's History navigation is backwards. I know why they did it that way (in the name of cross-browser compatibility), and most people, like balupton's history.js, get it wrong too.

In your app, you want to change the URL bar AFTER you navigate, not before.

Here's why:
  1. Your app should work without browser history manipulation, so you need some sort of navigation system in the first place
  2. You don't want to change the URL bar if the user doesn't want to leave the current form (because it's dirty)

Therefore, you need to try to navigate first, and only if it's successful, do you change the URL bar.

Unfortunately, Ext.History makes this impossible, as change() always fires after add(), no matter what you do (because there is a timer that polls the URL bar for changes every 50 ms).

HTML5 pushState and onpopstate do it correctly, in that calls to pushState() never fire onpopstate. onpopstate is only ever fired by the user, which is what you want.

Your navigation process should look something like this:

  • User is at "Tasks" screen, for example. URL is "#tasks"
  • User clicks the "Contacts" button or similar
  • Your app asks the current form if it is OK to navigate away (perhaps w a user confirmation dialog)
  • If not, do nothing. If ok, display the contact form. 
  • Update the URL bar to "#contacts", using pushState

  • URL bar is at "#contacts"
  • User hits the back button
  • URL bar is at "#tasks". onpopstate fires
  • App asks the Contacts form if it's ok to unload
  • If not OK, do nothing and change the URL bar back to "#contacts", usually with replaceState
  • If OK, load the tasks form

Tuesday, May 15, 2012

Disabling Chrome's Translate Function in your ExtJS Application

To disable Chrome's Google Translate function in your ExtJS app, add this to your <head>:


<meta name="google" value="notranslate">