ajaxsubmit question
| Project: | Javascript Tools |
| Version: | 5.x-0.8 |
| Component: | Ajaxsubmit |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
This request could be considered a little outside a regular support request - please feel free to ignore if you consider it inappropriate.
I have advanced flash/actionscript skills but I'm kind of a beginner in the Drupal/php arena. I'm more comfortable with the jQuery side of things.
I'm trying to understand your jstools approach and whether I can use it with flash instead of javascript, with partial success so far in a few experiments...I guess I'd probably best describe what I'm doing at the moment as 'learning'. If anything useful results I'd be happy to contribute back.
I'm stuck understanding the ajaxsubmit code. Specifically I'm confused by the use of $_SESSION['ajaxsubmit_destination'] in your code. I assume its intended for trapping the redirect url after a successful form submission/completion and returning that in the json data... but I can't see it being assigned a value anywhere. Am I missing something? And if I wanted to return the redirect url in a json data packet does it make sense to trap it (with some additional checks of $_POST data etc) from a hook_exit handler? (and then exit early after printing the json text). (I have done that but I suspect its not the right way).
#1
Hmm, I've reviewed the code and (a) you're right, there's something missing in this implementation and (b) I can't remember exactly what I was trying to do there. Sorry not to be more helpful! If you come up with suggestions as to if/where we should be setting the destination, please share.
#2
Possibly the idea was to allow other modules to set a destination? If so, though, one would presumably do that through a Forms API attribute on the form, like we already do with ajaxsubmit_target, rather than resorting to session handling.
#3
Thanks for taking a look nedjo!
All I could come up with so far was the hook_exit() approach... and I don't think that makes sense...(but I don't know).
I tried various form attributes. The #submit one kind of makes sense but its a little complicated under different situations.... if you capture the original $form['#redirect'] if it was defined and then set to FALSE for the form, that's easy if it was defined because it has the final say in terms of the redirect.... otherwise you also need to process the other #submit handlers which is the complicated part - at least I think so. I don't see how you can easily trap the last return value from the other #submit handlers... which would under normal circumstances probably be the redirect value I think.
In hook_form_alter I tried copying the existing #submit array into another form attribute/property (?not sure the correct lingo here) e.g. $form['#original_submit']=$form['#submit] and just having a replacement #submit handler in ajaxsubmit which then called the functions in the #original_submit...as they were originally intended to execute... to try to trap the last redirect value from the original #submit handlers... and then put it in $_SESSION['ajaxsubmit_destination'] like that... but I think I messed up doing it that way (if doing it that way makes sense at all). Like I said I can get the redirect value on hook_exit() and checking a couple of other things to make sure it was a redirect from a from submission and not something else. I'm trying to come up with general approach for all forms and not nominated ones. So... if its switched on it works for all. So far... not working. But if I can get it working, I'll definitely share how I did it (and hopefully someone can tidy up the code!).
#4
I only guessing here, but believe the reason you may have originally considered using the session variable is that you are reassigning the form['#redirect'] to "ajaxsubmit/dispatch" which provides a callback to the same function ajaxsubmit_dispatch so presumably you intended to store the original value of the redirect in the session variable for it to be accessible after the redirect... does that make sense?
The issue I think is catching the true value of the redirect as it should be from normal form processing - i.e. same as the difficulty I encountered - described above.
#5
Having just spent a while playing with this module trying to get it to work on all forms it seems that the only way to do it is trap the hook_exit as suggested by this GWD.
Unfortunately you don't have access to the form structure at that stage which means you have to look at $_POST for the ajaxsubmit flag and there is no way to abort or change the url so you need to manually call drupal_goto yourself for a second time. Very messy but I can't see any other way that you can catch up with all the redirect logic.
I also note that it seems to use the $form[#preview][#value] for previews, whereas 5.18 is using [#prefix]. Looking at common.inc it seems it the preview rendering is just appended to [#prefix] have I missed something?