Handbook documentation
NancyDru - June 2, 2009 - 14:44
| Project: | Import / Export API |
| Version: | 6.x-1.x-dev |
| Component: | Documentation |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Jump to:
Description
I really prefer to see some documentation BEFORE downloading a module. I started an handbook page for you at http://drupal.org/node/479742, I would recommend adding it to the project page. I could stand a lot more information.
#1
The import / export API has a lot of reference documentation included in the module's download package. If you want, you can read this documentation online through ViewVC.
#2
Since I have now downloaded it, I see that. But, as I said, I like to read about a module BEFORE downloading. Consider it sort of like sales literature. The pages are there now, so you might as well link to them.
#3
Reading through the doc there is a mention of a simple UI, can that be used solely without coding?
The rest of the doc seems to be coder oriented. :)
When I was reading through the doc it mentioned how you can define data types, I believe though defining data types is more convenient for most via the create content type interface. Can import export api use a content type as an existing data definition? So I dont have to code the defs? :)
#4
Thanks NancyDru. I'll take a look. I like online documentation as well.
@giorgio79: I hope to improve that interface by adding a mapping facility to the module. Currently this module will only import and export existing Drupal data. Anything else has to be coded as an add on module. A mapping facility would allow you to create a table for the file and then process it into nodes or process the file directly into nodes or use the created table with Views or ...
#5
@giorgio79: normally, when you want to support new data types in the import / export API, you need to code new definitions for those data types.
However, the API already includes definition support for CCK, and for its built-in field types (text, number, nodereference, userreference). So if you have a CCK type whose fields are only of these types, you shouldn't have to write any code in order to import / export it. If you use any other field types (from other contrib modules, or from your own custom modules), then you'll need to write definitions to support them.
#6
Enabling a Read documentation link from the project page (in the Resources section as usual) would be useful indeed.
#7
I've added the link to the project page. Leaving it in 'needs review' until I have a chance to read it.
#8
Thanks! Hopefully more people will look into this API.
#9
@earnie: It comes directly from your developer docs.