$.web2py.ajax_page events

[Paolo Valleri]

Dear all, 

please have a look here: https://github.com/web2py/web2py/blob/master/applications/welcome/static/js/web2py.js#L309

as you can see, the 'ajax:complete' event is the first thing accomplished in the complete event handler, after that we do all other stuff such as updating the page and setting all handlers for further requests. What is missing is that, we are not firing an event when the handler is really completed. I would fix this in order to allow an user to run some actions when an ajax request has been really completed.

I see two ways:

1- fire the event 'ajax:complete' as late as possible (namely at the end of the function)

2- fire a new event 'ajax:completed' at end of the function.

I am for 2, the first solution could raise backward compatibility issues.

if it is fine for all you I will make a PR later today or tomorrow.

Paolo

[Niphlod]

the real problem with web2py and ajax's handling is that ATM there are no ways to discern a "good" response from a bad one (i.e. form validation errors)
How would you stop the "process" based on the returned response if you move the 'complete' event ?
the rest of the "process" is fixed (those are all "internal" functions) ... what is the real limitation ?

[paolo....@gmail.com]

The real limitation is that, the event 'ajax:complete' is fired before the new html/js scripts and potentials js commands are executed; for this reason I need an event fired after.

I agree with you about the fact that we don't manage error at all, we should start to work on it too

 Paolo

2013/12/17 Niphlod <nip...@gmail.com>

the real problem with web2py and ajax's handling is that ATM there are no ways to discern a "good" response from a bad one (i.e. form validation errors)
How would you stop the "process" based on the returned response if you move the 'complete' event ?
the rest of the "process" is fixed (those are all "internal" functions) ... what is the real limitation ?

--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---
You received this message because you are subscribed to the Google Groups "web2py-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py-develop...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Niphlod]

then who says that ajax:complete should be fired e.g., after response.js ?
IMHO ajax:completed is in the correct position: as soon as the ajax request is completed and before any internal processing (being errors or correct responses).
BTW: instead of patching/improving the little things, shouldn't we instead focusing on fixing the "big holes" ? Lots of web2py.js is right now used just in admin's app: I'm fearing it's becoming a little bit too tailored and a little bit more complicated than it should just to support admin features.

[Massimo DiPierro]

Why features are, in your view, just for admin?

[Niphlod]

Just because the usecase has been made just for admin. No docs, no tests, no examples, no agreement on what should be stable....nothing, nil, zero.
I faced this before and IMHO until stabilized, new features should be added as users "ask" for them, not as an integral part of a single app that "backports" all of them, only to get later to a situation where a huge complicate refactor is needed because people on the meantime relied and developed on internals (unless all the additions are being treated as experimental), treating them as stable just because they see survival of functions between releases.
There are some huge "FIXME"s in the new web2py.js that are remaining unsolved while more and more whistles are added just to support specific usecases, and I can't see the point of adding undocumented/untested/experimental whistles that are not giving a bonus to the framework as a whole. 
This is a good example: since web2py is unable to provide meaningful status codes to treat them properly in ajax (the thing we should fix), we're debating on adding yet another "castle in the sands" to make an app (admin, I guess) behave as envisioned.

[paolo....@gmail.com]

@niphlod, if you see anything wrong I/someone made in web2py.js, then please open a discussion about that. 

I don't see wrong the fact that admin app is a use case for several js functions, certainly we should provide examples and document them all; btw, which are those "you don't like"?

For the request I made, you said

> "IMHO ajax:completed is in the correct position: as soon as the ajax request is completed and before any internal processing (being errors or correct responses)."

remind that at the moment we don't have any "ajax:completed" event, the only event is "ajax:complete" which is fire when the ajax handler is started not finished. 

In your view, the internal processing (being errors or correct responses) involves also the call 'update_page' which update the html content, my use cases is simple: I want to be notified when the html has been really updated.

Finally, we are talking about triggering a new event! Even in other js framework, i.e., bootstrap, I've already seen firing two events (one when the handler start, one when the handler ends).

 Paolo

2013/12/17 Niphlod <nip...@gmail.com>

[Niphlod]

On Wednesday, December 18, 2013 8:58:04 AM UTC+1, Paolo Valleri wrote:

@niphlod, if you see anything wrong I/someone made in web2py.js, then please open a discussion about that. 

I don't see wrong the fact that admin app is a use case for several js functions, certainly we should provide examples and document them all; btw, which are those "you don't like"?

this is the discussion. After letting pass 2 or 3 additions, it seemed the right time to raise a hand.

I don't dislike any of those, but the usecase is pretty limited and it'll remain that way, that's what I'm saying.