1. #11
    Sencha User
    Join Date
    Mar 2007
    Posts
    29
    Vote Rating
    0
    cchiriac is on a distinguished road

      0  

    Default


    No argue. For me it was just annoying to have to explicitly code "after you finish this, do that, but only sometimes".
    Also I was trying to make a difference between "synchronous" and "asynchronous and sequenced", "asynchronous and grouped" etc.

  2. #12
    Ext User
    Join Date
    Apr 2007
    Posts
    71
    Vote Rating
    0
    nbinder is on a distinguished road

      0  

    Default


    Just found this topic and totally disagree.

    If your whole application NEEDS to wait for a request in order to continue properly, a syncronous call is the right way. Using an asyncronous one and wait for it to complete, simply doing noops does NOT do it better (remember you need to wait and can't do nothing but showing a "please wait").

    Prototype supports syncronous calls, if you are looking for it. It works simply by
    asynchronous : false

  3. #13
    Sencha User krycek's Avatar
    Join Date
    Jun 2007
    Posts
    96
    Vote Rating
    0
    krycek is on a distinguished road

      0  

    Default


    i agree, something like "asynchronous : false" would be very useful
    it would make me save a lot of lines of code
    how Prototype do it?

  4. #14
    Ext User
    Join Date
    Jun 2007
    Posts
    3
    Vote Rating
    0
    danielv is on a distinguished road

      0  

    Default


    Quote Originally Posted by tryanDLS View Post
    You don't have to trigger the 2nd request from the callback of the 1st unless you need to chain the requests, or stop subsequent requests after a previous failure.
    I have a real need for either
    a) going synchronous
    b) manually blocking until the result of an aync call is available (which is more work than going synchronous and is ideologically equivalent to performing a synchronous call).

    We're trying to perform an operation which yields a decision during a drag event in a Tree, in order to determine if the current drag operation was successfully completed. If we go async, I need to block until the results of the AJAX call are returned in order to return the status of the drag.

    Perhaps you can suggest an approach which does not involve blocking, and can suspend the remainder of the event handlers until the result of an async call becomes available.

    In other words - how do I determine the subsequent handler currently bound to the event i am processing, conditionally over-ride it, and call it with the same parameters it was originally expecting without having to bend over backwards instead of simply making an exceptional use of the *evil* synchronous attribute already built in to the XmlRequest function?

  5. #15
    Sencha User
    Join Date
    Jul 2007
    Location
    Italy
    Posts
    134
    Vote Rating
    0
    fermo111 is on a distinguished road

      0  

    Default Sync for inclusion

    Sync for inclusion


    I agree with the these last posts. Sync/Asynch is a mechanism already built in XHR and it is there so that the programmer can chose what is best for the scenario he is implementing. Sync request have a very respectable name, RPC, and RPC have a long standing tradition. I cast my vote for the full support in Ext.

    Luca

  6. #16
    Ext JS Premium Member
    Join Date
    Jun 2007
    Posts
    30
    Vote Rating
    0
    Sunflower is on a distinguished road

      0  

    Default Another vote for synchronous calls in Ext

    Another vote for synchronous calls in Ext


    I agree that getting synchronous calls would be great in Ext (I worked on several 'real time' projects and logic as already explained makes sometimes a lot of sense).

  7. #17
    Ext User
    Join Date
    Aug 2007
    Posts
    6
    Vote Rating
    0
    shadun is on a distinguished road

      0  

    Default


    I think that adding a simple param asynchronous: false to the Ext.Ajax.request Config wouldn't be so hard to do. By not adding it you are forcing people to do what the framework wants, not what the user wants the framework to do for him.

    Anyway, I still think though that that param is not actually necessary. When I want e.g. to do something after my ajax request finished WITHOUT being able to use the callback function (for whatever reason) I use the Ext.util.Observable as a basis. I simply extend my object in which the call happens with that class, and then I assign an 'onload' handler, which the object fires using the fireEvent method from Observable just as I finish loading and rendering.

    Maybe that helps someone.

  8. #18
    Sencha User
    Join Date
    Mar 2007
    Posts
    186
    Vote Rating
    0
    Nullity is on a distinguished road

      0  

    Default


    See this thread for how to make a synchronous ajax call:

    http://extjs.com/forum/showthread.php?p=53192

  9. #19
    Sencha - Community Support Team hendricd's Avatar
    Join Date
    Aug 2007
    Location
    Long Island, NY USA
    Posts
    5,962
    Vote Rating
    10
    hendricd will become famous soon enough hendricd will become famous soon enough

      0  

    Default


    Quote Originally Posted by Nullity View Post
    See this thread for how to make a synchronous ajax call:

    http://extjs.com/forum/showthread.php?p=53192
    Nullity,

    Based on Ext-base async-only design (by design), your solution leaves 2 underlying timer/pollintervals unused and useless. They aren't even needed when making a sync call as they are blocked until the (current) XHR request is completed.

    However, I have added appropriate logic for synchronous calls to the recently posted AJAX override located here.

    Cheers.
    "be dom-ready..."
    Doug Hendricks

    Maintaining ux: ManagedIFrame, MIF2 (FAQ, Wiki), ux.Media/Flash, AudioEvents, ux.Chart[Fusion,OFC,amChart], ext-basex.js/$JIT, Documentation Site.


    Got Sencha licensing questions? Find out more here.


  10. #20
    Ext JS Premium Member ambience's Avatar
    Join Date
    Mar 2007
    Location
    Denver, CO
    Posts
    136
    Vote Rating
    0
    ambience is on a distinguished road

      0  

    Default My 2c

    My 2c


    I know it has been mentioned a couple of times but I would just like to reiterate that synchronous calls have their place. Namely, script dependency loading. Several of my scripts dynamic load components when they are constructed based on configuration information. I am unable to easily convert them to UX components to be shared because I am forced to rely on Prototypes synchronous request support.
    Last edited by ambience; 14 Sep 2007 at 8:45 AM. Reason: Because I am Retarded (capital R)

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