Hi,

This project seems quit and undertaking and its difficult to wrap my head around it.

My plan was to start creating my own project, codename "Execute Spreadsheet", that would allow me to work outside of Drupal and in my spreadsheet of choice (all spreadsheets support cvs so that choice should not matter)

Here is a mockup of how I would start creating a site.

http://screencast.com/t/gOorPa9Bg

In the blue table I would define my schema/structure/contenttypes.

In the green table I would enter data/content.

Every time I approach a new drupal site I start of with these excels that I validate with all the project stakeholders. I could have 30 content types with 5 fields so that makes 150 fields ... That takes me a full date/night to create with the Drupal GUI. And at the end my eyes are red and the brain is dead.

If I could upload this spreadsheet to my Drupal installation it would parse the file and create the content types and nodes.

Of course, this mockup is very simplistic and there are a lot of challenges and oppertunities

Challenges
- I do not define all of the properties of a content type. Only the required ones as specified.

If I later want to make a field mandatory I can do that through the Drupal GUI. The scope is not to make each and every field property editable. For example, I I have a date I can tweak it in a lot of ways like giving it an enddate, show nice jquery popups, etc... This is where the GUI excels and it would only complicate the spreadsheet.

- Only the human readable field names are listed.

Solution : the machine readable names can be easily derived. For example, Startdate => congress_startdate

- The spreadsheet should be validated on syntax before import.

It should happen as a transaction so no half work is done.

- The spreadsheet should be validated on content before import.

For example, there is already a node with ID 1. The validator would inform me of that, or better, remap that node id to the next available one.

- Round-trip engineering aka Achieving Nibana in Drupal :)

Not only should it be possible to import a spreadsheet. It would be nice, no awesome, if an existing drupal site could be exported to a spreadheet, make your modifications in the spreadsheet and import them back.
Date migrations/mass updates would become a lot easier right?

Shema round trips would make the scenario possible where you sit down with your stakeholders and go over all the content types and their fields and see if there are any missing.
The stakeholders look at a spreadheet and can create/update/delete them. Afterwards these changes can be discovered with a diff tool (Beyond Compare) or if the stakeholders did not validate the syntax they could be imported right away. Time for a cigarette now.

- I could go on but there are a lot of challenges no doubt

And now for the question, thanks for reading so far btw :)

Is this module intended for this or does it enable it? If this is the case kudos to you and how can I help you achieve your goals and make this particular use case possible?

I also want to contribute financielye. My plan is to give an amount that corresponds directly to the time I saved which in this case is a full 2-3 days (if roundtrip is also possible) for every new site. A model of contribution I use for every module that gets used in my sites.

Looking forward to your answer and insights!

Regards, Tom

Comments

Anonymous’s picture

In the blue table I would define my schema/structure/contenttypes.

I would create a custom module and add the schema using the schema API.

In the green table I would enter data/content.

I would create a custom routine that on the execution of the hook_install would be executed. The custom routine would look for a file called congress_data.csv and populate your congress table.

buckley’s picture

James Walker @ Lullabot pointed me to the interesting project http://drupal.org/project/patterns

This project seems really interesting from a development standpoint.

Grtz, Tom