Hello

I have quite a long programming career but only just started with Drupal (and of course the first big project needs to be implemented fast).

I know already quite well how to theme the site and that part goes fluently but the customer needs also the (anonymous users) to enter and describe their different projects to form a database. As there are dozens of different data fields per project the layout designers require the forms to be divided in four different pages (aka wizard) which may be filled at once or the user may return later to continue. Of course the projects are to be searched by different project categories (like 20 of them) and by a few other classifications contained.

I have thought a few alternative ways to implement it, please advise which might be the best practice here.

1. Project contents type (wondering if there is a feasible way to implement the paging for different pages)
2. A module (or a couple of them) with "internal" logic to manage the wizard pages
3. Building the logic "outside" Drupal, with Javascript and background scripts to talk with the database (probably outside Drupal's)
4. A combination of options: 1,2 and/or 3
5. Something I haven't even thinked about

I don't ask for exact implementation instructions but some pointers how to proceed would be appreciated a lot. Also any possible ponderings between different strategies would be valuable.

wbr

hank

Comments

WorldFallz’s picture

I do something very similar. I've implemented it such that one 'item' is actually 17 different content types each with a handful to a dozen or so fields.

I use panels, quicktabs, and views to collate and present all the various fields from the different content types on the parent (which serves as the container or main 'item'). AmdI use an entityreference field on each child content type to refer to the parent node to establish the relationship. There's all sorts of ways to enhance that so the data entry appears wizard like (I use entityreference_prepopulate and references_dialog). It works quite well and keeps the fields per content type manageable.

hcape’s picture

It basically sounds like a feasible solution. I have to digress a bit how to mold things according this model but unless something even more fascinating pops up it might be a good path to follow.

I only wonder, if one can program your solution (I have a dev drupal, test drupal and production drupal with all of them already "live") so deploying it would be more or less atomic [yes, I confess to have some experience in Sharepoint :/]

I see I still have a lot to conquer until I can say I am transformed to think in Drupal. ;)

hank

WorldFallz’s picture

I haven't set it up that way yet (it's currently a D6 system, and the last time I tried, d6 features was a nightmare), but it's one of the few things I would actually consider using features for (i'll be doing it in the d7 version of the site). it's basically just a collection of content types, fields, views, and panels config so it lends itself quite well to that.

hcape’s picture

I'll dive into it.

Actually it's something very similar to Sharepoint (even termwise), so maybe I can grasp it without too much hassle. :)

I appreciate a lot your input

hank