1. #1
    Sencha - Support Team slemmon's Avatar
    Join Date
    Mar 2009
    Location
    Boise, ID
    Posts
    5,030
    Vote Rating
    185
    slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold

      0  

    Default [4.1 B3] Bug in convert/set or am I just doing something wrong

    [4.1 B3] Bug in convert/set or am I just doing something wrong


    I tested the below sample script in 4.1 B3 and wasn't seeing what I was expecting.

    I'm hoping to have a store with two fields. Field A starts with a value of 100 and field B has no value, but rather a convert function to set the value of (fieldA * 2). This works the first time the store is initiated. In future iterations where I set a new value in fieldA the convert function does not seem to run on field B to update its value.

    Does this look like a possible bug or am I just doing something wrong?

    Code:
    var store = new Ext.data.Store({
        fields: [{
            name: 'fieldA'
        }, {
            name: 'fieldB'
            , convert: function (val, record) {
                console.log('fieldB convert message = ' + record.get('fieldA') * 2);
                return record.get('fieldA') * 2;
            }
        }]
        , data: [{
            fieldA: 100
        }]
    });
    
    store.each(function (record) {
        record.set('fieldA', 200);
    });
    
    store.each(function (record) {
        record.set('fieldA', 400);
        console.log('fieldA is now: ' + record.get('fieldA') + ' so fieldB should be 800 if the convert function ran')
        console.log('field B = ' + record.get('fieldB'));
    });

  2. #2
    Sencha - Ext JS Dev Team evant's Avatar
    Join Date
    Apr 2007
    Location
    Sydney, Australia
    Posts
    16,917
    Vote Rating
    630
    evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute

      0  

    Default


    Neither, really. The convert function gets fired the first time because it's setting the initial value, allowing you to do a convert the first time the data comes.

    After that, you're only ever setting the value of A, which doesn't have a convert function. Perhaps there could be some way on the model to setup a dependency that indicates that B relies on A, but as for now no such thing exists.
    Evan Trimboli
    Sencha Developer
    Twitter - @evantrimboli
    Don't be afraid of the source code!

  3. #3
    Sencha - Support Team slemmon's Avatar
    Join Date
    Mar 2009
    Location
    Boise, ID
    Posts
    5,030
    Vote Rating
    185
    slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold slemmon is a splendid one to behold

      0  

    Default


    I see. Is there a way to do a convert() action on a field ad ho today? Even if I have to do it manually per record update?

  4. #4
    Sencha User
    Join Date
    Apr 2011
    Posts
    4
    Vote Rating
    0
    swelan76 is on a distinguished road

      0  

    Default


    This seems like an inconsistency from previous versions to me. Up until 4.0.7 it was possible to build "virtual" fields like slemmon suggests using the field::convert function (fields that doesn't really exist in the json data returned from the server).

    In 4.1.0 the behaviour changed so that the convert function now really only acts like a default value (called on the first read and the value is then cached and convert never gets called for update operations).

    We have used this quite extensively (i.e. to create boolean "virtual" fields for checkboxes in a grid for example). Maybe we've misinterpreted the convert function, but it's been working that way since 3.x.

Thread Participants: 2