ImportExport API is a little rough around the edges when it comes to user-defined engines, definitions and fields. This is because it's hardcoded in places to only search for those in its own location, instead of looking in another modules directory. This can be likened to views, where it would be silly to expect another contrib to inject its files into views' directory.

This patch changes the file naming structure a bit. Instead of just having importexportapi_SOMEFILE.inc for engines, fields, and definitions, we change the file signature a bit for each, to eliminate ambiguity. This allows us to efficiently and automatically collect the files needed.

The new naming structure is as follows:

Fields: importexportapi_field_FIELD.inc
Engines: importexportapi_engine_ENGINE_CALLBACK.inc
Definitions: importexportapi_definition_MODULE.inc

I couldn't figure out how to make the patch automatically handle the filesystem changes, so I included the output from stderr which gives a good idea of what changed and where.

Thanks for reading, this will be a great improvement to importexportapi's extensibility if/when implemented.

CommentFileSizeAuthor
#1 importexportapi.file_collection.6.x.patch9.22 KBcha0s
importexportapi.file_handling.patch9.73 KBcha0s

Comments

cha0s’s picture

cha0s commented
StatusFileSize
new importexportapi.file_collection.6.x.patch9.22 KB

Hey, forgot I missed the engine include name changes in the last patch.

P.S. Anyone home..?

Anonymous’s picture

Anonymous (not verified) commented

I've had a sad last five weeks with dire family emergencies and a two week civic duty. On top of that my system hung up the email and I wasn't getting many delivered to me including your original post. I've been heavily involved with getting out a working beta version for xmlsitemap. I'll take a look at your patch ASAP; I'm trying to catch up on a lot of things. I do have a priority for getting this module improved and will eventually get to working on it. Thanks for the patch.

cha0s’s picture

cha0s commented

I'm going to commit this if no one has objections.

Anonymous’s picture

Anonymous (not verified) commented

How can you commit it, you don't have write access do you?

These are hefty changes to the structure of the module. I need review time. Jaza what do you think?

cha0s’s picture

cha0s commented

I do. I have been trying to let my changes be vetted.

I'm not just going to let my patches sit in purgatory forever though. :) If you want a little longer to do a review, fair enough.

cha0s’s picture

cha0s commented

Bump.

Anonymous’s picture

Anonymous (not verified) commented

Give me until this Monday at 19:00 UTC.

Anonymous’s picture

Anonymous (not verified) commented
Version: master » 6.x-1.x-dev
Status: Needs review » Needs work

I like what you are trying to do but I think we need to put these files in an importexportapi directory. Assuming module named foo we would then have modules/foo/importexportapi/fields_myfield.inc or modules/foo/importexportapi/engine_myengine.inc, etc. The patch also needs to provide an update path but we can work that out once we have the primary change down pat.

cha0s’s picture

cha0s commented

I waited months for a review and you didn't even explain why that should be done. ;) What's the reason we should require that?

Anonymous’s picture

Anonymous (not verified) commented

The reason is that it keeps the top module directory clean by putting the files relevant to importexportapi in its own directory.