for the last few days I've been trying to work out which would be the best way to handle the following scenario.
I designing a structure and want to identify which parts would be better to do as nodes and which would be better as taxonomies.
I'm trying to build a "database" of comic books.
I have a "title" which is then built up of a number of "issues".
each issue will have 1 or more "cover"
each issue will have 1 "summary" of what is in the issue.
so as an example
Title: Detective Comics
Issue: 345
2 Covers
1 summary
From a data perspective:
the title will just have a description field
the Cover would hold at least 3 pieces of data, a reference to the issue, a link to an image, and a name for the cover (this could be just the issue number or a text string to explain what was special about the variant cover such as "Comicon Variant"
The summary would hold about 5 pieces of data.
from a visitor perspective, I want to have a cover gallery (click on "Detective comics" and view all 400+ covers)
I also want to do the same for the summaries (the page that shows "detective comics" and the description would have an attached view of all available "summaries")
And the summary should have a view of all the covers for the same issue .
now my first thought was that as its a 1 to 1 relationship between issue and summary they would be the same content type so I would have 3 content types of Title, Issue Summary and Cover and use entity reference between them.
However the problem I have is that the cover will always go online before the issue summary. So the "issue" needs to exist prior to the cover and I want to keep data entry as simple as possible, so I don't want the person uploading covers to have to go create the "issue" entry.
So I thought, I could the title and issue be a parent -child taxonomy ( and use free tagging for the child)
That way the title and issue exists or is created as part of adding a new cover, and when the summary goes online it can use the same taxonomy, which I should be able to build the views I need.
but if i did this, pretty quickly I'd have 1,000+ taxonomies with similar child terms, for example:
Detective Comics
- 1
- 2
- 3
Green Lantern
- 1
- 2
- 3
So I'm kinda stuck in which is the best way to do this, any ideas?
Comments
a potential answer
So after doing a bit more research on how to make the admin side easier, I came across the field collection module.
need to test, but this may solve the issue as then the covers and the summary can exist on the same content type.
Yep!
Used the same idea to create a resume which has multiple education, work experience, and qualification fields entries.
Ade Atobatele
You could potentially use the
You could potentially use the "book" structure to group all issues of a comic "title" or use the "title" to tag all issues of a comic and/or its images (covers). This might work best for getting the covers into a gallery, though they could still just be fields of a comic issue.
See you at the Drupalcon!
thats a good point which I
thats a good point which I hadn't considered.
I've also wondered on how I handle "published" in the scenario using field collections.
The problem here is that once a cover is added, the "issue" becomes live,
so that means,or I believe it means, If a summary is added it's live straight away.
I'd like an "editor" to review and make it actually live ( 2 reasons, 1 for editing and 2nd for timing of the go live)
I didn't want to put to much workflow in for contributors and editors and was just going to restrict a contributor from the published option.
The more I think about it the more I confuse myself :p