Open direct bulk export to ”<option>Main” window like the single reco… #871
Conversation
…rd exports and trigger the change function also for the initially selected option.
|
Any chance you can elaborate on what problem you are fixing or what inconsistency you are addressing? I'm not exactly sure what to watch for while testing. (Sorry if it's obvious -- I haven't touched this code in a while, so a glance at the diffs isn't telling me much). |
|
If you export a single record from the full record view, target="Main" (e.g. RefWorksMain) is added to any redirect-style export elements (this is existing functionality separate from the export form here). This allows VuFind to stay in one tab/window while the system where the export is going is opened in another, and at least our users would like the bulk export to behave the same way. Previously the bulk export would open in the same window and the user would lose the context in VuFind. |
|
Thanks for the clarification! I'll give this a closer look (and compare notes with @crhallberg) in the near future. |
| @@ -61,10 +61,16 @@ | |||
| $('#format').change(function exportFormatChange(e) { | |||
| if (this.selectedOptions[0].getAttribute('data-redirect') === null) { | |||
| $('.export.btn').removeAttr('data-lightbox-ignore'); | |||
| $('.export.btn').unbind('click'); | |||
| $('form[name=exportForm]').removeAttr('target'); | |||
There was a problem hiding this comment.
Are you sure we want to remove the target from the form? I have a feeling this might cause problems in the Lightbox.
There was a problem hiding this comment.
As far as I can see there's no target in the form by default (that would cause it to open in another window in all cases!). It's only added by the "else" branch below the quoted part.
There was a problem hiding this comment.
I've of course also tested it with the lightbox and it works fine for me.
There was a problem hiding this comment.
My apologies, I mixed up target and action. You're correct.
To prevent click event stacking.
|
During debugging, Chris and I discovered a problem -- when the click action is unbound, things break. So this works if you go directly to an external export action, but if you click to an internal, download-oriented export (like MARC), and then switch over to an external action (like RefWorks), everything blows up. (By "blows up" I mean that if you try to perform the export, multiple lightboxes flash by, and then you're left with a non-functional grayed-out screen and no export tab). We discovered this because we were trying to refactor the code to prevent the problem of the click action getting bound over and over again if you switch back and forth between two external actions (e.g. flipping back and forth between RefWorks and EndNoteWeb a dozen times will cause a dozen different click actions to be bound and executed). However, this other problem seems even more serious -- we just didn't notice this until we tried to test uniform unbinding. Any ideas? Am I making any sense? (It's the end of the day -- my brain may be a bit foggy). |
|
Ah, thanks for catching that and trying to fix it. Binding multiple times is bad, indeed, but so is unbinding since it will remove Lightbox's handler too. How about the just-committed version? This always adds the click handler (once), but it doesn't do anything for a download-oriented export. |
|
I think this is much better. Excellent. I'm going to look into a solution to so easily erasing Lightbox's bindings. |
- Open direct bulk export to ”<option>Main” target (i.e. new tab/window) like the single record exports - Trigger the change function for the initially selected option for consistency
…rd exports and trigger the change function also for the initially selected option.