Create D7 version
katbailey - July 2, 2009 - 05:40
| Project: | Quick Tabs |
| Version: | 7.x-2.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | katbailey |
| Status: | needs work |
Description
OK, I've made the pledge, I'd better get this done!

#1
I am not sure about this one. As jquery UI made it into Drupal core, we should fully leverage its functionality.
from the demo and docs as I see it is more flexible than the current quicktabs js, so it would be a shame to go with a simple port.
http://jqueryui.com/demos/tabs/
http://docs.jquery.com/UI/Tabs
are you coming to Paris?
#2
No, unfortunately I am not coming to Paris :-(
Changing the title - we need to have something for D7, whether it's a port or not.
I'm all for leveraging ALL of the new stuff, particularly js stuff, that is now in Drupal 7, however I'm not convinced there's much to be gained from using jQuery UI tabs. The tab functionality is the simplest part of Quick Tabs, the trickiest part is getting the required content into those tabs. I know jQuery UI tabs does have an ajax option but it might be too simple for our needs, taking things like views settings into account, although I think we will no longer need to load all these on page load - we can pass them locally in our callback.
Anyway, lots to think about - what in particular from UI Tabs do you think would enhance QT?
Oh, I guess one other point very much in favour of using UI Tabs is consistency - it would mean wherever you have tabs on a page, whether from QT or anywhere, they're always built the same way.
#3
First crack at a Drupal 7 version of quicktabs. No changes to JS are included in this patch, just DBTNG changes and other misc changes to the Drupal API.
Patch against HEAD and re-rolled D7 module attached.
Note: relatively untested.
#4
Files are missing one comment line that was accidentally removed.
Re-attached.
#5
Thanks for the help Ryan. The main problem with your version is, that it does not use the latest code. Function like "quicktabs_aj_form" was removed long time ago.. The HEAD branch is deprecated, the latest D6 code is in DRUPAL-6--2 branch..
I also started to work on the D7 version, you can download my latest code here: http://windmill.sk/project/module/quicktabs
only the admin UI works.. and no views, as the views module is not ready for D7..
I would like to make a solid base for quicktabs, so my next goal is to make them exportable with using #535122: Integrate CTools export.inc into core for declaring instances of objects
My other big plan is to use ctools for tab content configuration and tab content display, but that module is also not ready for D7, so I just want to be sure that I can switch to it later..
Feel free to work on the required changes to display a quicktab, with or without jQueryUI, or post any bugs and suggestions..
#6
I don't use the quicktabs module myself, I just picked a random #D7CX-tagged module and went for it. Hopefully there is something of use in the patch I contributed. I'm afraid this is the extent to which I can contribute at this time.
#7
No problem, but you should really use this module in the future ;)
#8
just another ref link: #544418: Integrate CTools AJAX framework with Drupal to extend (and replace) existing ahah framework
#9
Pasqualle, can you please commit your D7 code to HEAD?
#10
I will commit the code tomorrow, just want to finish the changes on the admin interface..
#11
The straight D7 port of the 6.x-2.x admin interface is committed into DRUPAL-7--2 branch. The admin interface works.. Katherine please work with this code, only the quickab rendering is missing (don't make improvements to admin interface).
I did not commit my latest code as it is totally broken now. Trying to make the quicktab object and the UI more flexible, something like the views UI. Will post the code later, but probably will have to port ctools first, as the code getting more and more complex with every step..
Attached image is not from the latest version, but it shows the new (but not final) interface.
#12
Thanks Pasqualle, I'll work on this tomorrow.
Also, here's another core patch that's (hopefully) about to be committed and will make ajax submission on our admin form simpler to handle: #370537: Allow Partial Validation of Forms (aka, make "more" buttons work properly)
#13
I've added basic quicktabs functionality (http://drupal.org/cvs?commit=257754). Some notes:
@pasqualle the new admin interface looks awesome! Can you just explain the dependency on ctools? I'm not clear on where that comes in. Is this just for making QTs exportable?
#14
I think we need to find a better name for quicktabs instance, because I need to make a difference between "1 quicktabs" and "2 quicktabs", the first should be singular and the second should be plural name of quicktabs instance..
probably a "QTabControl" or something http://msdn.microsoft.com/en-us/library/system.windows.forms.tabcontrol....
I think the version does not really matter, I just followed the habit of other module maintainers (like views for D6). It is possible to re-start from 1 for Drupal 7, but it is also possible to continue the version from the previous Drupal version.. I think the later is more common, for example cck 7-2.x or admin_menu 7-3.x for D7.
So on the screenshot every small gray box is a different form, and all boxes have 1 common template and the whole page has 1 template. This page on the screenshot almost worked, just the "tabs" box gave me a headache. It did not work with the old ajax form submit call (reset all other forms), nor with the new ajax callback (the tabs table should be replaced, but there is no theme function for the table (the add tab button is part of the theme function), or the replace would work with rendering a form, but the build_form('tabs_table', $tabs) do not work inside ajax call, and it is not easy to modify the actual form to insert or remove one tab from the table). So after trying several options which did not work, I decided to rewrite the UI as the views UI works, to fix the tabs box problem and also to make the UI even more flexible. But the views UI uses plugins to display the options form for every item (when you click on it), the views UI functionality is not from ctools, but it is the same plugins functionality. So after reading the views UI functionality, and started to implement it, I just saw that it will be too much code, and most of it would be a duplication of ctools plugins..
And also if we want different tab content types, we should use ctools, as it has all our current content types: block, node and view with better settings (like display node comments with nodes is a setting in ctools), and it also has panels.
And the export also needs ctools, as I see the export functionality is not getting committed to D7.
So ctools should make the QT module more modular and maybe even smaller with more functionality..
#15
the BLOCK_NO_CACHE constant was removed today
#495968: Introduce drupal_render() cache pattern. Start using it for blocks
http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/block/block.module...
#16
it is called DRUPAL_NO_CACHE now
#17
no need to call install/uninstall schema
#306151: Automatically install/uninstall schema
#18
http://drupal.org/cvs?commit=276256
The module works with Drupal HEAD
#19
http://drupal.org/cvs?commit=276612
Ajax stuff now working - couple of small problems still: if you add a tab, then the ajax setting doesn't get applied to the new remove button. I did have this working yesterday so there must still be some slight discrepancy between the code I was working with yesterday and Pasqualle's latest code from cvs, will look into it. Also, note that you need to update Drupal from HEAD again as this very important (for qt) patch just got committed: #595654: AJAX command 'settings' broken