PDA

View Full Version : [CLOSED] Store "write" event not firing



alanmies
28 Nov 2011, 3:21 AM
I've written an ExtJS <-> CouchDB interface, which seems to work fine with ExtJS 4, but not so with Sencha Touch 2.0 (PR2). First of all, I run into this (http://www.sencha.com/forum/showthread.php?150673-localstorage-proxy-sync-error-Batch.js-related) issue, although my proxy is a subclass of RestProxy. That is easily fixable with the instructions in said thread; but when I call sync() on my custom store, the POST goes ok, but the write event doesn't fire. And because of this, the document doesn't recieve an ID, and remains as phantom. But the store is loaded, so I suppose it is being used... any ideas?

(As for the obvious question to why reinvent the wheel, CouchDB uses a REST interface, right? It does, but it also requires "_rev" field with every request, except when creating a document, and it returns only "id" and "_rev" when updating a document, so some customization is required)

mitchellsimoens
28 Nov 2011, 7:14 AM
What is your response like when the write POST happens?

alanmies
28 Nov 2011, 7:47 AM
The response is 201 Created, content-type is text/plain but the actual content is JSON, like {ok: true, id: "$GENERATED_UNID", _rev: "1_$GENERATED_REVISION_NUMBER"}. The values returned are determined by CouchDB.

But just noticed something - when I first saw this problem, I started to debug it with Firebug; I know Webkit is the only supported platform for Touch, but I prefer Firebug over Chrome developer tools. However, Chrome actually points out the problem, it is within the constructor of Observable. The error is "Uncaught TypeError: Cannot use 'in' operator to search for 'listeners' in true" - the listeners definition in my custom store is rather simple, it only defines a write method that parses the response and updates the id and _rev. Is the definition of listeners somehow different in Sencha Touch compared to ExtJS? As said, the same code works fine with ExtJS 4.

mitchellsimoens
28 Nov 2011, 7:51 AM
In ST2 they are a little different.

alanmies
28 Nov 2011, 8:07 AM
Well for what's it worth, here's the definition:

listeners: {
write: function(store, operation) {
var response = Ext.JSON.decode(operation.response.responseText);
var doc = operation.records[0];
doc.setId(response.id);
doc.fields.add('_rev', Ext.create('Ext.data.Field', { name: '_rev' }));
doc.set('_rev', response.rev);
}
}

That should be valid? As for why adding the field "_rev", CouchDB requires it, but only when updating a document. When creating one it must not be sent, so the proxy removes the field when creating a document. This is a kludge, I know, if there is a better way to tell "thou shall not send field x" please do tell me.

(I noticed that there was a typo in my previous post, the response includes "rev", not "_rev", the latter is the term used internally with CouchDB though)

alanmies
15 Dec 2011, 12:59 AM
After some testing (with the latest PR 3 even), I've come to the conclusion that this is due to how the event is defined, and is not related to stores in particular. A brief test case:


Ext.define('Panel1', {
extend: 'Ext.Panel',
initialize: function() {
this.on({ show: function() { console.log('showing Panel1') } })
}
});


Ext.define('Panel2', {
extend: 'Ext.Panel',
listeners: {
show: function() { console.log('showing Panel2') }
}
});

Ext.application({
launch: function() {
Ext.create('Panel1').show();
Ext.create('Panel2').show();
Ext.create('Ext.Panel', { listeners: {
show: function() { console.log('showing Panel3') }
}}).show();
}
});


Yes, I know, one shouldn't use show(), this is just an example. The above code will log in the console "showing Panel1" and "showing Panel3", so using either method for defining events seems like an acceptable workaround. But will the method for defining events in Panel2 be supported in Sencha Touch?

TommyMaintz
16 Jan 2012, 2:44 PM
I think the one for Panel2 doesn't fire because you havent put the listeners in the config: {} object in your class definition. There was a bug related to the listeners that was fixed a while back. Not sure if thats in the currently public release.

In any case, this bug is not related to the Store or data package, and I will thus be closing it. If the problem still exists, let us know so that I can open another ticket with an appropriate description in our system.