PDA

View Full Version : Model convert function in 4.1



rondinos
11 Oct 2012, 5:54 PM
It looks there is a major change between 4.0.7 and 4.1

I have a convert function in my model that converts a GMT date to local.
On 4.0.7 I was converting them back to GMT before save and it was working like a charm.
On 4.1 it looks like that after I convert the date to GMT, ExtJS is running the model convert functions and it's converting it back to local before doing a POST.

I guess a temporary solution would be for me to convert it to GMT twice, (e.g. jump +4 twice) and when ExtJS runs the convert, it would be the correct time before sending the POST but I am looking for a more elegant solution because I will have to update many files in order to support 4.1

Is there a way that I can fix this globally ? to kind of skip running the convert of the model before sending data to the server ?

This is the code I am using


if (valid) {
if (mode == 'create') {
record = new model(values);
gridview.getStore().add(record);
} else {
record = form.getRecord();
record.set(values);
}

win.close();
gridview.getStore().sync();

rondinos
12 Oct 2012, 7:05 AM
I noticed that it happens when I call the sync function. Is there a way to sync the records as they are without converting them ?

This is a major change between 4.0.7 and 4.1. I hope there is a solution

mitchellsimoens
14 Oct 2012, 10:20 AM
Every time you set data to a model it's going to execute the convert method as you are telling it to do.

rondinos
16 Oct 2012, 5:44 PM
I really don't understand why is this so different from 4.0.7 and why there is no backup solution to skip it in 4.1

mitchellsimoens
17 Oct 2012, 4:14 AM
The behavior should be the same

skirtle
17 Oct 2012, 3:51 PM
A convert function needs to satisfy:


convert(convert(a)) === convert(a)

Strictly speaking the relationship isn't ===, for reference types they just need to be conceptually equal, but hopefully you get what I mean. Adding a couple of hours to a date definitely won't satisfy this relationship.

This is fine for simple type-conversion but if you're writing a custom convert function it can get pretty annoying. The reason is that several sections of the library need to ensure conversion has been performed for a value and you can end up with it being run through convert twice if you happen to go through two sections of code that perform the conversion.

If you only want to do the conversion at read time (i.e. not when the set method is called) then you could use a mapping function instead. The docs for this are here but they're just plain wrong because they advise using a convert function:

http://docs.sencha.com/ext-js/4-1/#!/api/Ext.data.Field-cfg-mapping

If you take a look at the source you'll see that mapping can also be a function. I think this was only added in 4.1 but the docs haven't caught up yet. Using a mapping function is the best way I've found to do a conversion just at read time.

rondinos
22 Oct 2012, 4:40 PM
Thank you for the reply skirtle but I think there has been a little misunderstanding.

I said earlier "I noticed that it happens when I call the sync function"

The problem is not when the set method is called, it is when I call sync. It looks like that in 4.0.7 it was syncing with form.getValues() and now it syncs with record.data. The difference is that in 4.0.7 my ajax request is not really affected by the .set function because it syncs with my form values.

Perhaps this was a bug in 4.0.7 but for me it was a workaround and it's really unfortunate that there is no backup solution.

skirtle
22 Oct 2012, 5:15 PM
Thank you for the reply skirtle but I think there has been a little misunderstanding.

I said earlier "I noticed that it happens when I call the sync function"

Possibly. I'm increasingly unclear what you were originally asking. You're walking through a minefield of possible problems and it's not entirely clear which mine you're hitting.

The response from the sync will also be run through the reader/convert mechanism. Perhaps that's where you're problem is occurring?

The bottom line is that a convert function really isn't cut out for doing timezone conversion because it will keep adding on extra hours each time it gets called. This is unfortunate though as in ExtJS 3 it would have been a good place to do it. The move to calling convert all over the place is relatively recent and I know I'm not the only one who thinks it was a mistake.


The problem is not when the set method is called, it is when I call sync. It looks like that in 4.0.7 it was syncing with form.getValues() and now it syncs with record.data. The difference is that in 4.0.7 my ajax request is not really affected by the .set function because it syncs with my form values.

This doesn't sound right. Syncing a store won't pull values from a form using getValues. I think you're misinterpreting something somewhere.

Incidentally, it isn't clear why you're using a store for syncing your records. If it's just one record you'd be better off using the save method on the record instead.


Perhaps this was a bug in 4.0.7 but for me it was a workaround and it's really unfortunate that there is no backup solution. I would really like to know how the mapping works with a function in 4.1 because it doesn't work the same way as convert.

You can either work it out by reading the source code, or just log out the arguments using a console log and deduce it from that. From memory I believe it gets passed the root of the data and you have to return the relevant value.

rondinos
22 Oct 2012, 6:10 PM
I figured out how mapping as a function works and again this is not a solution.

The problem is that I have to send to the server the GMT time. So what happens now with mapping, is that since set is not running the convert function and I am setting the GMT time before the sync, now the grid shows the GMT during the syncing until I get back the server response. So I am clicking Save and during the time of syncing I am seeing the wrong time, until I get back the server response.

It's really unfortunate how a little change from your side can cause so much trouble in an application.

rondinos
22 Oct 2012, 6:18 PM
Incidentally, it isn't clear why you're using a store for syncing your records. If it's just one record you'd be better off using the save method on the record instead.

This is exactly the reason why I am using sync instead of save. Because in 4.0.7 it would sync with my form values and everything was working like a charm. It is multiple records.