This is REALLY counter-intuitive. Are there any plans to improve Ext.create(..) to load nested data?

4 Feb 2013, 2:11 PM

matthewdfleming

Here's how we did create...

We had this same problem in sencha touch.. the solution was like this..

This code is in a button click handler for a 'create new assessment' button. The idea is that a create call is supposed to be made to the server and the result of that call should be an 'Assessment.' The json stream coming back has entries for all of the related items (e.g. categories, assessor, etc).

Code:

var me = this;

// create a new assessment with the client and tool
var newOne = Ext.create('helium.model.Assessment');

And I also wanted to send this as a whole to the server, so it will save the role and permissions in a single request.

I saw the helium example above, but the importante part to me (the helium.util.IncludeRelationshipJsonWriter) ) was not shared (the code).

How could that be done ?

22 Sep 2014, 12:47 PM

matthewdfleming

IncludeRelationshipJsonWriter.js

This is what we used, that totally worked but it's been a while. Good luck..

Code:

/**
* This class extends the normal Json writer so that related objects are sent down to the server on the CRUD operations.
* The default Sencha writer only sends the data from the top level object being saved. I found two ways to send
* down the relationship/nested data, one is to define a field using the same name as the relationship (don't do
* this), and two to write a writer that does it (this class).
*
* The problem with the first solution is this.. If you define an object like this:
* fields: [
* .. other fields
* {name: 'anotherField', persist: false},
* {name: 'categories'}
* ],
* hasMany: [
* {model: 'helium.model.Category', name: 'categories'}
* ],
*
* In the definition above there is a field that is the same name as the relationship (hasMany). The problem is
* that the attribute 'persist' will not be respected for any of the Category objects.. So if you want to exclude
* attributes from being sent to the server (persisted), the above workaround won't do it.
*
* This class does solve that problem and you should not define a 'field' with the same name as an association.
*
* This is an amalgam of the ideas @:
* http://www.sencha.com/forum/showthread.php?141957-Saving-objects-that-are-linked-hasMany-relation-with-a-single-Store
*/
Ext.define('helium.util.IncludeRelationshipJsonWriter', {
extend: 'Ext.data.writer.Json',
/*
* This function overrides the default implementation of json writer. Any hasMany relationships will be submitted
* as nested objects. When preparing the data, only children which have been newly created, modified or marked for
* deletion will be added. To do this, a depth first bottom -> up recursive technique was used.
*/
getRecordData: function (record) {
//Setup variables
var isPhantom = record.phantom === true,
writeAll = this.getWriteAllFields() || isPhantom,
me = this, i, association, childStore, data = {};
if (writeAll) {
data = me.callParent(arguments);
} else {
var changes, name, field, fields = record.fields, nameProperty = me.nameProperty, key;
changes = record.getChanges();
for (key in changes) {
if (changes.hasOwnProperty(key)) {
field = fields.get(key);
name = field[nameProperty] || field.name;
data[name] = changes[key];
}
}
if (!record.phantom) {
// always include the id for non phantoms
data[record.idProperty] = record.getId();
}
}

//Iterate over all the children in the current association
childStore.each(function (childRecord) {

//Recursively get the record data for children (depth first)
var childData = this.getRecordData.call(this, childRecord);

/*
* If the child was marked dirty or phantom it must be added. If there was data returned that was neither
* dirty or phantom, this means that the depth first recursion has detected that it has a child which is
* either dirty or phantom. For this child to be put into the prepared data, it's parents must be in place whether
* they were modified or not.
*/
if (childRecord.dirty | childRecord.phantom | (childData != null)) {
data[association.get('name')].push(childData);
record.setDirty();
}
}, me);

/*
* Iterate over all the removed records and add them to the preparedData. Set a flag on them to show that
* they are to be deleted
*/
Ext.each(childStore.removed, function (removedChildRecord) {
//Set a flag here to identify removed records
removedChildRecord.set('forDeletion', true);
var removedChildData = this.getRecordData.call(this, removedChildRecord);
data[association.get('name')].push(removedChildData);
record.setDirty();
}, me);
}
}
//Only return data if it was dirty, new or marked for deletion.
if (record.dirty | record.phantom | record.get('forDeletion')) {
return data;
}
}
});

22 Sep 2014, 10:56 PM

adrian_crouch

As far as i remember we solved that the way skirtle proposed. We've rolled out that functionality into a model utility class and are only working against a ModelUtils#create function when populating an associative model. That works as expected and is the most time-consuming approach w/o implementing too much extra code that might not work anymore in a subsequent release.

Code:

Ext.define('ExtBbiAC.ModelUtils', {

statics: {

/**
* Creates a new pojo with the help of a JSON reader. This allows to create a pojo with associations
* which is not implemented by the Ext.create() nor Ext.data.Model.create() operation as they do not
* use a reader when populating a model.
* @param model Obligatory.
* @param config Optional.
*/
create: function(model, config) {
var reader = Ext.create('Ext.data.reader.Json', {
model: model
});
var resultSet = reader.read(config);
return resultSet.records[0];
}
}
}

23 Sep 2014, 7:38 AM

matthewdfleming

One last thought...

I've moved away from doing large object graph saves. If I want to save the children pointed to a parent, I'll just send the children. If I want to save a parent object, just save the parent. The trouble starts when you have the idea in your head that you must send the parent object to save the relationships to the children. Or even worse the relationship to the children plus any edits to a child.

My point is that after getting everything to work, I realized this was really an anti-pattern rather than something that was desirable. I hope the code helps you, but I'd probably move a different direction if you can.

3 Feb 2015, 5:32 PM

HriBB

You can use Ext.data.Model's static getProxy() method to get the reader and read records manually: