PDA

View Full Version : Why doesn't Ext.create('Model', ...) load associated model data?



ykey
23 Aug 2011, 5:25 AM
I am having trouble loading associations through Ext.create. The following works fine when data is retrieved through a server proxy. However when the same data is loaded through Ext.create no associations are created.

The UI component depends on the nested stores and I would like to have default data available if the AJAX call fails or times out and for testing purposes.



Ext.define('Server', {
extend: 'Ext.data.Model',
idProperty: 'name',
fields: [
'name'
],

hasMany: {
model: 'Container',
name: 'containers'
}
});

Ext.define('Container', {
extend: 'Ext.data.Model',
idProperty: 'name',
fields: [
'name'
]
});

var sys = Ext.create('Server', {
"name": "Server 1",
"containers": [
{
"name": "A"
},
{
"name": "B"
},
{
"name": "C"
}
]
});

console.log(sys); // Has 3 containers in the data field
console.log(sys.containers()); // Has 0 records

skirtle
23 Aug 2011, 7:21 PM
I agree that what you're trying to do appears sensible but it doesn't work. My guess is that associations are handled at the reader level and using Ext.create() skips that. It seems very counter-intuitive to me.

It took me quite a while to find a way of doing it that actually worked. Maybe there's a better way but this is what I came up with:


var reader = Ext.create('Ext.data.reader.Json', {
model: 'Server'
});

var resultSet = reader.read({
"name": "Server 1",
"containers": [
...
]
});

var sys = resultSet.records[0];

All feels a bit yucky to me. I don't see anything there that couldn't be done implicitly in the model's constructor.

devnullable
25 Aug 2011, 7:01 AM
I feel your pain guys. I was just wondering what's going on when associations are not loaded on Ext.create. Working on anything more "complex" than in examples, like a form with grids of associated model data is really frustrating experience. Build JSON by hand for saving primary model AND association models in same atomic AJAX request and then try to figure out how to load back response again... :-/

skirtle
25 Aug 2011, 6:16 PM
I've got this on my list of ExtJS 4.0 issues. I believe 4.1 addresses a lot of the shortcomings of 4.0 so I'm waiting for that release before I throw in a 'feature request' for this.

mberrie
13 Sep 2011, 6:35 AM
Is there a bug report for this? I wouldn't expect 4.1 to fix an issue just because it is obvious that a feature is incomplete. ;)

skirtle
13 Sep 2011, 6:51 AM
I've seen comments from the Sencha devs that 4.1 will improve the data model, particularly associations. I don't know the details but I can't be bothered spending hours filing reports on issues until I know what's in 4.1.

I think the word bug may be a little strong in this case.

S├ębastien.Volle
18 Apr 2012, 5:19 AM
From what I've seen in 4.1 RC3, Ext.create('Model', ...) or new Model(...) still does not create association data in the Model instance. One still have to go through a reader for the associated data to be built.

Is there any plan for adding that in 4.1 GA? When instanciating a model instance, when all the required data is provided, I don't see why association data should not be there in the instance.

gjuggler
29 May 2012, 9:46 PM
I've started running into this problem too.

It seems silly that associations can be loaded from serialized formats via the JSON and XML reader classes, but not from an in-memory data structure via the standard Ext.create() call. It's an unfortunate oversight in the API design.

I'd love to see this fixed in a future release!

dougi
2 Aug 2012, 1:38 AM
i thought first that it was a bug on my side but it's worst. Can we expect a correction soon?

jcervenka
2 Aug 2012, 8:06 PM
This works:
http://stackoverflow.com/questions/10104739/populating-associated-models-with-nested-json (http://stackoverflow.com/questions/10104739/populating-associated-models-with-nested-json)

Qanik
13 Nov 2012, 11:15 PM
This is REALLY counter-intuitive. Are there any plans to improve Ext.create(..) to load nested data?

matthewdfleming
4 Feb 2013, 2:11 PM
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).



var me = this;


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


// save it so that the 'create' call will happen on the server
newOne.save({
success: function (record) {
// for some reason the 'create' flow doesn't resolve associations
// need to manually push through a reader
var reader = Ext.create('Ext.data.reader.Json', {
model: 'helium.model.Assessment'
});
var resultSet = reader.read(record.data); //the record itself won't work, just the .data portion
var assessment = resultSet.getRecords()[0];
// 'assessment' is now fully read in with associations
},
scope: me
});


Here's the model object (using a REST proxy).. the writer is a custom writer that will also push all of the related items down on a save/update call..


Ext.define('helium.model.Assessment', {


extend: 'Ext.data.Model',
config: {
useCache: false,
fields: [
'id', 'version', 'startDate', 'type',
{name: 'allowedActions', persist: false},
{name: 'status', persist: false},
{name: 'baseType', persist: false},
{name: 'major', persist: false},
{name: 'minor', persist: false}


],
hasMany: [
{model: 'helium.model.Category', name: 'categories'}
],
hasOne: [
{model: 'helium.model.Assessor'},
{model: 'helium.model.OrgUnit'},
{model: 'helium.model.Client'}
],
proxy: {
type: 'rest',
writer: Ext.create('helium.util.IncludeRelationshipJsonWriter'),
api: {
create: '../data/assessment/create',
read: '../data/assessment/read',
update: '../data/assessment/update',
destroy: '../data/assessment/delete'
},
reader: {
type: 'json',
rootProperty: 'assessment'
}
}
}
});

hdave
3 Feb 2014, 4:14 PM
Yet another person that found this thread. I am using 4.2.2 and am frankly stunned that this doesn't work. I really hate the idea of creating a reader just to do this....

adrian_crouch
5 Jun 2014, 7:15 AM
It neither seems to work with extjs 5 .. :(

rockskull
22 Sep 2014, 9:41 AM
Sorry, to revive this thread, but I'm having the same problem.


I Have a Role screen. This rola has many permissions.

I want to make a form, that you can fill up the role fields, and add permissions to a grid (related to this role).

I though in using role.permissions() as the grid's store. But them I saw it's not possible.

I also wanted to load (in case of editing a role) all role's permissions to a grid, so the user can edit this permissions.

I'm loading the json once, something like:

{role: {name: "", description: "", permissions: [{name: ""}, {name: ""}]}}

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 ?

matthewdfleming
22 Sep 2014, 12:47 PM
This is what we used, that totally worked but it's been a while. Good luck..



/**
* 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 hasMany associations
for (i = 0; i < record.associations.length; i++) {
association = record.associations.get(i);
if (association.get('type') != "hasmany") {
continue;
}
data[association.get('name')] = [];
childStore = record[association.get('storeName')];


if (childStore) {


//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;
}
}
});

adrian_crouch
22 Sep 2014, 10:56 PM
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.



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];
}
}
}

matthewdfleming
23 Sep 2014, 7:38 AM
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.