PDA

View Full Version : [FIXED] Convert functions on model fields broken



Sottilde
7 Mar 2012, 2:05 PM
Two issues here:

The major one:

Adding a 'convert' function does not automatically add the parameters (value, record), nor is there any way to add them.

So code like this is generated:


name: "date_relative" , type: "string"
, convert : function(){
return Date.relative(record.get('date'))
}


This triggers an error because 'record' is not being passed.

The minor one:

Including a return function in your convert function triggers a "Return not in function" error.

Basic functions, as well as convert functions, all appear to have this issue.

Sottilde
7 Mar 2012, 2:11 PM
They are also strange to edit.

I had to create three convert functions on three fields in a row. The first was fine. The second, after clicking the +, already contained the code of the first. I deleted it and put in new code. The third had the same behavior as the second, so I also deleted the code and put in new code.

Upon a save, the code in the editor changes back to the code of the first convert function. Double-clicking the highlighted convert function loads the correct function.

This particular bug seems to be a UI annoyance only.

Sottilde
7 Mar 2012, 2:28 PM
This particular bug seems to be a UI annoyance only.

It's worse than I thought - my second and third convert functions are not being written to the Generated Class at all! They remain accessible in Designer and in the metadata but they do not make it into the code.

aconran
7 Mar 2012, 2:45 PM
It's worse than I thought - my second and third convert functions are not being written to the Generated Class at all! They remain accessible in Designer and in the metadata but they do not make it into the code.

Confirmed; thanks for the bug report.

aconran
7 Mar 2012, 3:51 PM
This will be fixed in the next release > 309.

Sottilde
7 Mar 2012, 5:16 PM
This will be fixed in the next release > 309.

Is it possible to get this build? This bug is severely holding us up.

Phil.Strong
8 Mar 2012, 8:43 AM
Planning another update for tomorrow

Sottilde
11 Mar 2012, 8:16 AM
The fix in 311 works great, thank you, although there are some oddities when removing existing convert functions, to switch over to the new type.

If a user had previously defined a 'convert' function in a field, and clicks the + next to convert (which is in custom properties, because it was previously overridden), the new 'convert' function is still broken as per the original post. There is no value or record being passed in. In addition, a red flag is placed next to the convert function that says "This function is overriding a config set by you".

Deleting the 'convert' custom property from the field leads you up the creek without a paddle as you are unable to define another convert value.

Clearing the 'convert' custom property from the field does the same as, while it will clear the "This function is overriding..." warning, it still will not pass (v, rec) into the function.

The only fix I have found to make this work properly is to delete the 'convert' property by right clicking it, then duplicate the field and delete the original. This makes 'convert' show up properly under "Ext.data.Field" and not under (Custom Properties).

I don't know if this is a priority for you as it will only affect users upgrading from older builds.


Here is one small bug that is still present (and effects lots of function definitions):

Using the 'return' keyword triggers the error "Return not in function". A minor annoyance.



Thanks again for the fix, guys.

aconran
12 Mar 2012, 9:22 AM
Thanks Scott, we are aware of all the above.