It will be useful at least in some cases to dynamically load local task tabs, e.g., views that are presented on tabs.
The tabs library has support for something similar, but it's designed for all tabs, not just ones that are not visible.
Here's what I imagine we'll need:
* On load, iterate through local tasks.
* For currently active local tasks, wrap its content in a holder div. This requires the ability to distinguish what its content is (which may be difficult).
* For all non-active local tasks, create a new holder div and dynamically load their content into the div (via ajax).
* Process all tabs. This is pretty much the reverse of what we currently do. That is, currently we take a set of code that's in the form expected by the tabs library and mark it up so it looks like Drupal local tasks. Here, we take local tasks and mark them up so they're in the form expected by the tabs library.
Result: we preload all data into tabs and the user can switch back and forth between them.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | tabs-dynamicload.patch | 2.68 KB | nedjo |
Comments
Comment #1
nedjoHere's a patch that implements dynamic loading of primary tabs for local tasks.
I've followed the approach I outlined. To determine what to display of the active tab, we iterate through the next siblings of the div enclosing the tabs. This seems to work.
We use dynamicload to load the tabs' content. I've added an option to load content directly rather than waiting for user clicks, http://drupal.org/node/126890.
The main problem with this patch is the problem with almost all Drupal AJAX: we end up with broken content, because Drupal behaviours don't attach to the newly loaded content, see these two issues:
http://drupal.org/node/125153
http://drupal.org/node/120360
For example, node add/edit forms are broken because the collapse behaviour doesn't attach but the css triggered by the presence of js hides the fieldsets.
Also, we probably don't want this on all pages all the times, as it means extra loading, e.g., everyone with edit nodes permission will load an edit form for every page viewed.
So, for 5.x, we need a way to limit this to pages where we know it will work. I suppose:
* module developers can call the code to add the js as appropriate
* we add a page filter like the one used for blocks so site admins can limit it to given pages.
Does this sound right?
Comment #2
nedjoI've been testing the patch. It works pretty well. One bug I've found is that the active tab is not correctly set--it always defaults to the first tab.
Comment #3
nedjoI changed this to not apply by default, due to Drupal AJAX issues noted above. Instead I've added a method that other modules can call, passing an element reference so that only certain tabs will be processed.
Comment #4
(not verified) commented