1. #1
    Sencha User
    Join Date
    Mar 2012
    Location
    Seattle
    Posts
    9
    Vote Rating
    0
    markbjerke is on a distinguished road

      0  

    Default HasOne Association, Suggestion: provide event in addition to the callback for load

    HasOne Association, Suggestion: provide event in addition to the callback for load


    In the case of associated models that are loaded async I see a need for an event in addition to the standard getter method with callback(s).

    The reason being the callback notification is limited to the first caller of the getter method. Subsequent callers examine the (returned) associated model's phantom flag and notice that the model is being loaded. But I don't see a way for notification when the associated model is ready for subsequent callers of the association getter method.

    It would be simple to add a 'link' ( name ?, associate ) event to the owner model that is fired with an argument of the type of association and of course the associated model upon load ( the standard event signature with operation object etc...)

    An event would reduce complexity on the part of the calling code which in the case of multiple code paths accessing an assoication has to manage the arrival of the data in an awkward manner with home grown events.

    The argument that the caller(s) can provide any kind of event deemed necessary ignores the observation tht the arrival event for an association's model belongs in the owner model 's code, not the calling code.

  2. #2
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    35,724
    Vote Rating
    752
    mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute

      0  

    Default


    In the callback you can easily fire your own events.
    Mitchell Simoens @SenchaMitch
    Sencha Inc, Senior Forum Manager
    ________________
    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
    https://github.com/mitchellsimoens

    Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/

    Need more help with your app? Hire Sencha Services services@sencha.com

    Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!

    When posting code, please use BBCode's CODE tags.

  3. #3
    Sencha User
    Join Date
    Mar 2012
    Location
    Seattle
    Posts
    9
    Vote Rating
    0
    markbjerke is on a distinguished road

      0  

    Default Kinda / Sorta...

    Kinda / Sorta...


    Looking at the createGetter methods on BelongsTo and HasOne; there is an else clause that is entered for subsquent callers of the association(s). The else clause is entered when an instance has been attached ( either a phantom or a the actual associated model ) to the owner model from an earlier call to the getter method.

    The else path invoking the callback is useless in cases where the data has not arrived. The code path in the else simply calls immediately with the phantom model that was created and attached to the owner model from the first call to the getter method. So the only callback that is of any use in terms of determining when async data is available is the first caller's callback. ( the not else clause code path )

    I guess I could put in logic in all my callbacks for associations that fire an event when data arrives.

    In a large app there are many code paths referencing async data., You don't want to be in a situation of playing 'who was first' with differing logic. It really isn't a good design to have the caller assume responsibility for notifications involving an associated model.

    Other people will hit the same uncertainty and awkward handling that I did when they call getter methods and are not the very first caller while the record is being fetched.

    It's awkward, right now. Please fix this. Your customers will enjoy the consistency down the road.


    Code:
    // Overwrite the success handler so we can assign the current instance                success = options.success;				failure = options.failure;                options.success = function(rec){                    model[instanceName] = rec;                    if (success) {                        success.apply(this, arguments);                    }					// (MB) - added link event					if( associateEvent ) {						Ext.defer(function()						{							model.fireEvent('link', me.ownerModel,  me, rec); 						},1);											}                };				// (MB) - added link event				options.failure = function(rec, operation) {					if (failure) {                        failure.apply(this, arguments);                    }					// MB					if( associateEvent ) {						Ext.defer(function()						{							model.fireEvent('link', me.ownerModel,  me, rec, operation); 						},1);					}                };                associatedModel.load(foreignKeyId, options);

Thread Participants: 1

film izle

hd film izle

film sitesi

takipci kazanma sitesi

takipci kazanma sitesi

güzel olan herşey

takipci alma sitesi

komik eğlenceli videolar