You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 8, 2021. It is now read-only.
Currently, any unexpected response to loadpage will render a blank page saying "undefined". It would be really nice (and I think quite simple) to turn this in to an extension point instead. When responseHeaders are not html, trigger a custom handler with the data.
In concert with this, the code which shows the yellow error dialog could be move in to its own accessible method. Which could, in turn, be used by such a handler.
This could be used by json data returned from server errors or in a more lightweight form validation.
Thoughts?
The text was updated successfully, but these errors were encountered:
Based on the description you've provided I'd be interested if the extension point we provide with pagebeforechange would serve (http://jquerymobile.com/demos/1.0/docs/pages/page-dynamic.html). In general this is a tool for the "I want to handle the request myself, including the page generation" scenario.
The only reason I ask is that I'd like to gauge the value of what you're proposing with regards to the more general solution we've provided.
Hmm. It looks like I can latch on to pageload event and there scan data.xhr.getResponseHeader('Content-Type') for json, calling any necessary handlers and stopping further propagation.
At this point data.page has already been populated (with undefined content) and added to the dom- a possibility for optimization.
Would still be great to be able to access that dialog independently.
Added to the wiki!
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Currently, any unexpected response to loadpage will render a blank page saying "undefined". It would be really nice (and I think quite simple) to turn this in to an extension point instead. When responseHeaders are not html, trigger a custom handler with the data.
In concert with this, the code which shows the yellow error dialog could be move in to its own accessible method. Which could, in turn, be used by such a handler.
This could be used by json data returned from server errors or in a more lightweight form validation.
Thoughts?
The text was updated successfully, but these errors were encountered: