2

I'm currently working on a project with a new requirement that, in a nutshell, queues submissions from users and submits them them to a remote API:

  • collects submissions from users (with a form)
  • each submission points to a record on a remote system (uuid provided by remote API)
  • each submission has a status (ie: new, accepted, declined)
  • each submission stores a number of other fields of data
  • each submission references a node id that already exists in drupal
  • submissions with a status of "new" are presented to an administrator, who can accept or decline them (the queue)
  • changes to submissions are audited
  • submissions are never published as content, as they may contain personal info

Much of the data being stored for each submission is simply for interaction with the remote API. Only a small amount of the data for each submission is for human/administrator eyeballs.

I began architecting the storage for these submissions - basically just a really wide database table with one column that references a node id. The database table will also need to be exposed in Views, so that I can easily build pagable, filterable & sortable html tables. Will also perform some custom bulk operations (View Bulk Operations).

I'm now debating if it would be wiser to use a custom node type with a pile of CCK fields to store these submissions as unpublished nodes, rather than building it all custom. On the downside, I'd have to do a lot of form_altering to get the submissions form to where I want it, and I really don't need a lot of node functionality (workflow, comments, titles, etc, etc). On the plus side, if using nodes+cck the Views integration comes for free, and it's likely quicker to build.

I'm working in Drupal 6, and an upgrade to Drupal 7 is at least a year out - but it's also something I need to consider when making this decision.

Any thoughts?

Improve this question

2 Answers 2

Reset to default
2

Go with CCK.

I've done this in Drupal 5, and I'm doing it again for Drupal 6. It's really not that hard to get this going. You gets all kinds of things for free both with CCK and Views. You already mentioned the benefits for Views, but it's the same for CCK. You simply create everything you need from the UI, and then export it to a file that gets read during your install hook.

Also, why write your own CRUD?

I'm doing something very similar. Take a look at my code over at Syndeploy.

I haven't exported the Views code yet, but I'll get there.

Improve this answer
1
  • Thanks for your feedback. Interesting project, I'll keep an eye on it. Personally, I've been using Features + SVN to manage the deployment of cck & views with great success.
    – rcourtna
    Commented Jul 21, 2011 at 15:53
0

Sincerely, I'd build my own tables and information architecture.

You'll end up spending too much time fiddling with external information (cck) rather than actually getting your stuff to work.

Improve this answer
1
  • Thanks for your response. I've been leaning this direction. My only concern is that I'll burn too many cycles exposing my tables to Views - however, I'm prepared to take the plunge. Thanks!
    – rcourtna
    Commented Jun 1, 2011 at 16:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.