Make views integration exportable

A reasonable request - not at the top of my priority list, but I would welcome a patch.

Soo, I gave it a shot. It could DEFINITELY be made nicer, but my basic testing indicates that it works (and all simpletests pass). Ain't much to it: on admin/content/tw, I added a second button for exporting the selected tables; it then takes you to a form with the output dumped out per the typical cck/views/panels exports.

I abstracted tw's actual hook_views_data() implementation a bit; the entire meat is now in a separate include file and broken into two functions that take some arguments so that we can get a subset of tables (which we need for the exporter) versus always getting all the tables (as needed for the hook implementation). So yeah, both the exporter - which is just a menu callback to a gateway function, a quick form, and the recursive var exporter - and the hook implementation use the same functions to hit the db.

One big thing jumped to mind on ways this could be improved that would make for better UX, although no significant difference in capabilities: the module could allow the exporting of all the tables for a particular module, which would mean we could even turn the output generated into the entire .views.inc file for that module, from the initial php tag onwards. It'd be kind a backwards to have to go through the database in order to do that, though, so doing that the cleaner way would require some more time in order to let the exporter build & access data directly from the core table analytics that tw does.

Just a note, I'm not attached to the file names, function names, etc. that I used in there, or any other stylistic stuff. And, I brain farted on how to do multi-step forms, so the export is generated via some awkward arg-pulling and checking right now. I SWEAR there's a stupid-easy way to push it through $form_state... ;P

Hmm. Just realized that that patch probably doesn't handle t() properly. Will check later today.

New version of the patch. re: Ken's items:

-- Fixed the checkbox title; also reorganized the form a bit, as it's more standard to have operations on the far right.

-- Man, I always forget about db_placeholders...too much time in drupal 5. Fixed.

-- The are problems with misuse (the 'group' property, for example, was set via t($disptablename), and in the columnar data function several variables were being dropped straight into the string) but I was actually focused on what's missing: a number of the properties that should have their values wrapped in t() in a normal hook_views_data() implementation were coming through as just plain strings. So I added a little wrapper that makes those all come out nice.

-- Mm, yes, that's more standard, thanks. Switched to commas. I'd still rather a multi-step form, but I'll prolly leave that to someone else to do...

Shouldn't be. The operation really isn't that complex, and it still does it with just two big queries (same as in the hook_views_data() implementation); there are just some constraints that limit results to only the requested tables.

It works right now. I think the question is: Can it work better?

We should also see if the export can include relationships defined by the module. And the Help text should probably come from the field comment in the schema, not the fields name.

Small patch which cleans up some of the t() issues and needs to be merged to the larger patch.

I also notice in my testing that the 'relationship' handling in _tw_generate_views_columnar_data seems to be reversed. That is, I have to invert the base and related tables in the UI to get the relationship to export.

Note: the relationship handler does not currently export the JOIN data we need.

I promise, I'll review and commit this someday soon... I haven't got much time this week, and the migrate module is in even more need of attention...

Just a quick note: there are some oddities with the order in which items get generated - specifically, I'm accustomed to seeing the 'table' portion of a table definition come first, before any of the field definitions - but that's really a minor point, and could probably be easily fixed.

More interesting, though, is that we've been talking a lot on our end about how great it'd be if tw could generate proper relationship/join information. The data currently available to us would require that be done using heuristics on field names, which is just silly, so it isn't really feasible now - BUT! Crell alerted me to #111011: Add foreign keys to core, which if it gets in, would give us almost all the metadata we need to generate join data. The only thing it would be missing is which table to use as a base table - which we could solve internally by just asking people to include some data in their schema indicating a base table, but also by adding a form widget that allows the site admin to specify a base table from which to work. Once we have foreign key and join data, that ought to be sufficient to figure out how to arrange all the joins.

...of course, if that goes into core, it'd also mean that Views could figure out most of it natively, so long as a base table gets specified. In fact...heh. Wow, yeah, that'd probably end up being a GREAT patch to Views. Time to talk to Earl...

Chatted with Earl. Yup, specifying base tables is the key here. There are still questions about how intermediary/join tables get routed through, but it's still a heckuva lot more auto-figured-out stuff that can be done within views - basically, any direct neighboring tables, Views will be able to do itself.

:) sweet!