You could always get the best of both worlds by doing what Zohar suggests re: making each item an individual node, but also providing a single form interfacing for submitting a collection. In this case, on form submission, the individual nodes would be programatically created in the backend. You could even do the magic of creating the 'collection' view at this stage. It could either be dead-simple or prohibitively difficult to set this up, depending on your level of familiarity with PHP and the Forms API.
William
On 9/10/07, Jean Gazis jgazis@gmail.com wrote:
I think that probably provides more flexibility in the long run. It's not an e-commerce site. I'm concerned the the client will find entering 12 items separately more cumbersome than just doing one form.
Jean
On 9/10/07, Zohar Stolar z.stolar@gmail.com wrote:
Yes, it's better for you to have a content type for "wine", and then you can do different things with it. Think of a wine as one entity. 12 wines can be an entity if they are bundled in one package, but a single wine should be on its own.
Jean Gazis wrote:
I want to have a content type for a monthly list of about a dozen wine selections. I created the content type, and created fields for one wine, and I can add new fields or existing fields from a _different_ content type, but I don't see any way to copy the first set of fields on the _same_ content type. Is there a reason for this? Do I have to have Name for wine #1, and then Name2 for wine #2 and so on?
Would I be better off to have a content type for "wine" and then have a view that shows the 12 most recent?
-- Jean Gazis www.jeangazis.com http://www.jeangazis.com www.boxofrain.us <http://www.boxofrain.us >
"Believe those who are seeking the truth; doubt those who find it." - André Gide
-- [ Drupal support list | http://lists.drupal.org/ ]
-- Jean Gazis www.jeangazis.com www.boxofrain.us
"Believe those who are seeking the truth; doubt those who find it." - André Gide
-- [ Drupal support list | http://lists.drupal.org/ ]