The dialog buttons object allows you to configure action buttons to be displayed in the bottom pane. It's a simple configuration, as it's just an object. The key is the button label and the value is the callback function for click events. We can create as many of these buttons as we like. Typically, we pass the dialog button configuration object to the widget when it's being created. However, we can pass in the button configuration at a later time, after the dialog has been created. Possibly after it's already being displayed for the user. This configuration is handy, but not without it's limitations. Chief among them, configuring the callback functions themselves.
Showing posts with label callback. Show all posts
Showing posts with label callback. Show all posts
Thursday, October 17, 2013
Thursday, March 11, 2010
Handling Callback Variables
With Javascript applications that make asynchronous Ajax requests, does it make sense to store a global variable that indicates the callback that should be executed? That is, depending on the current state of the application, a different callback function may need to execute for the same API call. Should a global variable be set before the request is made and checked each time by the response?
That doesn't feel right to me. Neither does sending application data along with the API request just to be used by the callback. That would mean sending application state to the server which isn't a good thing as far as I'm concerned.
I like the idea of listening for certain events that the callback might emit during execution. The callback might emit a certain type of event each time it is run. The events are always emitted but the application may not always be listening. When the application is in a certain state, it will be listening. The handlers of these events could be considered secondary callbacks.
That doesn't feel right to me. Neither does sending application data along with the API request just to be used by the callback. That would mean sending application state to the server which isn't a good thing as far as I'm concerned.
I like the idea of listening for certain events that the callback might emit during execution. The callback might emit a certain type of event each time it is run. The events are always emitted but the application may not always be listening. When the application is in a certain state, it will be listening. The handlers of these events could be considered secondary callbacks.
Labels:
ajax
,
application
,
callback
,
event
,
javascript
,
state
Subscribe to:
Posts
(
Atom
)