4.1 UPDATE:

As an update... in 4.1 there is now a static method setFields which can be used to define the model prototype fields. It works well in a controller s init method.

When I did this, I wanted to have some static fields defined in the model class and then set some more dynamically. Unfortunately the new setFields method replaces all fields with the argument, it was easy enough to handle though.

This example uses the MVC pattern where my model and store are included in the controller s model array and store array (providing me with the handy getters used below):

Ext.define( ST.controller.Main , {
    extend:  Ext.app.Controller ,

    models: [ User ,  Reference ],

    stores: [ CurrentUser ,  PermissionRef ],

    views: [ MainPanel ],

    init: function() {
        var me = this;

        me.getPermissionRefStore().on( load , function(store, records) {
            var model = me.getUserModel();
                // this returns the static fields already defined 
                // in my User model class
                fields = model.prototype.fields.getRange();

            // add the permission options (dynamic fields) to the static fields
            Ext.each(records, function(permission) {
                fields.push({name: permission.get( name ), type:  bool });
            });

            // 4.1 method to update the User model fields
            model.setFields(fields);

            // now load the current user (it will use the updated model)
            me.getCurrentUserStore().load();

        });

    }

});

The User model and CurrentUser store are created exactly like regular, non-dynamic models and stores would be and included in their respective controller arrays, the User model is simply missing the dynamic fields which are added as shown above.

I also went into that problem. I have a service which is responsible for fetching metadata from the server and adapting the models and stores to this metadata.

I therefore defined an empty model and configured the store to use this model.

When the meta data is processed, I add the new/additional fields to the prototype of the model like this (metaDataStore is the store containing the meta data, model is the model which can be obtained from the model manager):

var fields = [];
metaDataStore.each(function(item) {
    fields.push(Ext.create( Ext.data.Field , {
        name: item.get( field )
    }));
});
model.prototype.fields.removeAll();
model.prototype.fields.addAll(fields);

When I then call load on a store using this model or create new model instances the new fields are processed correctly.

Here s a very simple example. Just use a normal Ext.data.Store but instead of a model, specify the fields property:

// you can specify a simple string ( totally )
// or an object with an Ext.data.Field ( dynamic )
var fields = [ totally , {name :  dynamic , type :  string }];
var newStore = new MyApp.store.Object({
  fields : fields
  // other options like proxy, autoLoad...
});

Don t specify a model property - it seems that it would override the fields property.

I also wanted to change the columns and content of an existing grid dynamically:

// reconfigure the grid to use the new store and other columns
var newColumns = [
  {header:  Totally , dataIndex:  totally },
  {header:  Dynamic , dataIndex:  dynamic }
];
myGrid.reconfigure(newStore, newColumns);

From the Ext JS 4 documentation about the "fields" property of Ext.data.Store:

This may be used in place of specifying a model configuration. The fields should be a set of Ext.data.Field configuration objects. The store will automatically create a Ext.data.Model with these fields. In general this configuration option should be avoided, it exists for the purposes of backwards compatibility. For anything more complicated, such as specifying a particular id property or assocations, a Ext.data.Model should be defined and specified for the model config.

So be careful - Sencha may remove it in the future.