Closed (fixed)
Project:
Features
Version:
6.x-1.0-rc1
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Reporter:
Created:
16 Aug 2010 at 15:24 UTC
Updated:
2 Sep 2010 at 22:10 UTC
Jump to comment: Most recent file
I've got a good example of this going with riat right now.
http://github.com/EclipseGc/riat
If you create a definition and then manage it, you can add relationships to the definition. Features will allow you to export both the definition and the relationships (both are currently labeled riat_core on the features select drop down, the second one is the relationships). These will export to code just fine (didn't even do that in beta 11) but they are still missing from info file.
Use case:
I have a unique name/child id set of columns within the table structure, but ctools isn't keen on using a compound unique key, so I provide an rid as a serial, and then throw it away in the export (merlin actually advised me to do exactly this). The problem being that since features is keying on the primary key in my export, I'm only going to get the serial in the list. List callbacks allow me to change that for the better, but once I use it, features stops liking it. :-(
Eclipse
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 884624_ctools_crud_v2.patch | 5.65 KB | yhahn |
| #7 | 884624_ctools_crud.patch | 5.27 KB | yhahn |
| #5 | 884624.patch | 801 bytes | eclipsegc |
| #4 | 884624.patch | 739 bytes | eclipsegc |
Comments
Comment #1
eclipsegc commentedSorry mis-marked the version.
Comment #2
eclipsegc commentedok, so apparently got my wires crossed on this because the exported file doesn't appear to be there either, so the $module.default_hook_name.inc for an exportable with a custom list callback doesn't get created in addition to the the info file issue.
Comment #3
eclipsegc commentedAfter looking into this a little more, it appears that hook_features_export_render() is not being called for components w/ their own list callback. Still trying to nail this one down.
Comment #4
eclipsegc commentedThe ACTUAL problem here is that features makes use of ctools_export_load_object(), which if a custom 'list callback' is utilized will probably not resolve (since the list is probably no longer keyed on the primary key of the system). Further more it doesn't actually make use of the custom 'load callback' available in export which ctools_export_crud_load() now does. So I've switched the system to utilize that instead, they return nearly identical data, so this was very easy to do. Then a custom load callback for my weird exportable makes everything go back to working properly. I have my proper file for the hook, and items in my info file so this makes me very happy.
Earl had mentioned to me that ctools_export_load_object() needed to be switched to ctools_export_crud_load() if possible, so I'm pretty sure this should be our method going forward if possible.
Hope this all makes good sense to everyone else.
Eclipse
Comment #5
eclipsegc commentedEarl pointed out to me that I was creating an array and destroying it. Sorry wasn't paying attention was just trying to produce identical output.
Comment #6
yhahn commentedLooks good, but if possible I'd like to have a fallback to calling the load callback directly to ensure that people using CTools < 1.7 don't crash and burn.
Comment #7
yhahn commentedRerolled patch, this uses wrapper functions to contain the version checking craziness that can be deprecated once CTools 1.7+ becomes widespread.
Comment #8
yhahn commentedProperly use list callback for options.
Comment #9
yhahn commentedCommitted: http://drupal.org/cvs?commit=409822