Add an "afterSubmit" option to hook_popups().
quicksketch - November 18, 2008 - 22:01
| Project: | Popups API (Ajax Dialogs) |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
This patch adds a new option for "afterSubmit" to hook_popups(). The "afterSubmit" option makes it possible to call a JavaScript function after successful submission of a form through a popup. We're using popups to dynamically update multiple parts of the page at once, so the existing targetSelectors option is not enough. Adding a custom callback allows us to make any changes we desire with the returned data manually, rather than depending on popups to simply inject the new content into the page for us.
If desired, the afterSubmit callback can return the value "false", and skip all remaining processing normally done by popups.
| Attachment | Size |
|---|---|
| popups_after_submit_function.patch | 786 bytes |
#1
I like it.
I am curious where the targetSelectors option falls short. You know it accepts a hash as input right?
#2
Hmm, I realized this patch isn't even going to be much help to me. In a previous version of popups.js, the DOM object for the link that was clicked was passed into the Drupal.popups.formSuccess() function as a third parameter "a". Without it, this patch doesn't add a lot of value.
The scenario we had was configuring blocks on the page, inline. A "configure" link was added to every block on the page using a single selector "a.block-edit". The problem was after the block had been reconfigured, we needed to update that block with the new contents of the block. We used the "a" parameter to identify which link had been clicked on and therefor which block had just been edited. We'd find the parent DIV containing the block and update it with the new contents of the block.
So I'm moving this to code needs work, since you're right, it doesn't do anything new without knowing contextual information about what was actually clicked.
#3
#4
Here we are, this re-instates the "a" parameter that was removed several revisions of popups ago. My guess is that popups.js never needed the "a" parameter, so it was just taken out to clean things up a bit. However, in our case it'd be very helpful to have that information when running a custom afterSubmit function.
#5
That last patch had a small bit of unnecessary cruft. Here we are again.
#6
Hmm, ok, I get how this is useful if you have context. You can't name the variable 'a' though. One of nedjo's patches made it possible to trigger popups on any type of element. So the obvious variable name is 'element', but you will have to make sure that 'element' isn't already being used in one of those function.
#7
Seems like "element" was free in all contexts, here's a reroll.
#8
It passes my hairy eyeball test, but I still try it out.
Can you reroll against D6-dev when it becomes available?
#9
Here's a reroll against the latest CVS.
#10
That looks like a reroll of the original patch, not the improved one from #7.
#11
I'm a dunce. I uploaded the wrong file. :P
#12
Ok, I am branching to 6--2 for this patch and #336641: Auto-load needed JS and CSS files (and settings). The 6--1 is now closed to new features and will be just for bug fixes. Of course, I added a bunch of new comments and code cleanups before branching, and now this doesn't apply any more. Sorry.
Also, in Drupal.popups.formSuccess
Drupal.popups.openContent(data.title, data.messages + data.content, options);
should probably be
Drupal.popups.openContent(data.title, data.messages + data.content, options, element);
#13
Hey guys! I found I need this function pretty badly unless I wanna keep using popups-form-reload, in which case my status messages aren't retained. So here's the patch rolled against the latest 6.x-2.x-dev
I just manually read Nate's patch and also took into account your suggestion in #12 Tao.
#14
Looks like I did something wrong here... #popups element is being duplicated with this patch... hrm
#15
also, this is not available when trying to use on-popups-options and should be documented as such.
#16
I see what went wrong here, there was a line you had commented out that I uncommented. This was causing the dup. Here's a revised patch that so far seems to be working correctly for me.
#17
Ok, I still haven't really wrapped my brain around the js/css loading stuff over in 2.x-dev, so I have wrapped this patch into the upcoming 1.2. It fits in with the lifecycle event triggers I am playing around with (which, might be a better way to get the same effect, but I don't have any afterSubmit callbacks to test, so I am not sure).
#18
Automatically closed -- issue fixed for 2 weeks with no activity.