I am still far from being comfortable with Drupal. Here is a problem case I need to solve.
I have huge list of musicians who have played for my past gigs and recordings. Many of them has their own website. Some of them will be listed for future shows.
I would like to create 3 sections, Discography, Musicians, and Schedule, where I want to call names from the list of musicians along with its hyperlink for their site.
I've got CCK and View, but I am not certain how I should plan this. Any comment would be appreciated.
On Wednesday 16 May 2007, A-NO-NE Music wrote:
I am still far from being comfortable with Drupal. Here is a problem case I need to solve.
I have huge list of musicians who have played for my past gigs and recordings. Many of them has their own website. Some of them will be listed for future shows.
I would like to create 3 sections, Discography, Musicians, and Schedule, where I want to call names from the list of musicians along with its hyperlink for their site.
I've got CCK and View, but I am not certain how I should plan this. Any comment would be appreciated.
You're already on the right track, then. :-) I'm not entirely clear as to your data model, though. Are Discography, Musicians, and Schedule all lists of all musicians on file, just showing different data? Are they searchable/sortable?
I'd defintely start with a Musician node type (or Artist, or whatever). That contains all the data about a single musician. Try to figure out what data on them will be category-like in nature and which is "part of" the musician. For instance, web site and number of people in the band are "part of" the musician entity. For those, use CCK fields. Whether their music type is rock, jazz, or disco would be a category-style bit of data. For that, use a taxonomy vocabulary called "Music style" with possible terms rock, jazz, and disco.
From there, you can create lists of musicians using Views by whatever attributes you want. Eg, all musicians who play jazz, name and web site. All musicians with more than 3 people, grouped by their music type. Etc.
For Discography, there's lots of ways you can do that. You could have an "albums" field on a musician node that just lists album titles. Alternatively, you could have an Album node type that has a nodereference field that points to the musician node responsible for it (as well as year, label, who did backup vocals, etc.). That gives you the ability to create lists (Views) of album nodes, too, with links to their musician, grouped by musician, etc. I'm sure you can think of lots of other cool things to do with that sort of data.
You may or may not want to go this route directly, depending on what it is you're lookig to display, but hopefully the above gives you an idea of how to go about designing your data model "the Drupal Way". I would definitely advise erring on the side of a richer data model that you're not using rathern than a simple one that you may outgrow. You can certainly make headaches for yourself either way, but IME it's better to have too many options than too few.
Cheers.
Larry Garfield / 2007/05/16 / 11:56 PM wrote:
You're already on the right track, then. :-) I'm not entirely clear as to your data model, though. Are Discography, Musicians, and Schedule all lists of all musicians on file, just showing different data? Are they searchable/sortable?
Thank you so much for your detailed response. It was a great help for thinking process, while I realized I should had mentioned an example.
Say, I have my own show the day after tomorrow. Both vibraphone player and the bass player are also performing for someone's jazz orchestra with me on Saturday. The guitar player for my show Friday have played for a few of my CDs, while both of us played for someone else's CD as well as major commercial shows.
See, we the jazz musicians go wherever calls us. This is why there will never be a band with steady members. My original band will never play again since the drummer has moved to NYC and touring all the time, and the pianist became a successful Verve record artist. In other words, the list of musicians who collaborate/collaborated with me is quite long. We have to grab who is best and available for the show date every time.
Example: I want to have next show announcement promoted on the front page. I maybe the leader, or I may be playing for someone's show. I want to list the musicians for the show. You click on one of the names. The new node of the musician opens, where all the recordings and the gigs that musician played with me get listed as well as the hyperlink to the musician's home page.
Boy, it sounds a lot of work required already.
My current site's, not Drupal but simple PHP partially done by myself, schedule section is done with 3 MySQL tables, one for the show date, one for each band I am currently working for, and one for the venues we often play. I only need to add the show to the date table, and the band hyperlink and the venue hyper link are automatically attached. I was hoping something similar to this data model to the musician list (tho I have to plan for this Schedule data model in Drupal 5.1 as well).
Do you think I should just create a site with simple pages first then improve later? I am kinda afraid I will never finish Drupal site if I am stuck like this on each steps.
On Wednesday 16 May 2007, A-NO-NE Music wrote:
Larry Garfield / 2007/05/16 / 11:56 PM wrote:
You're already on the right track, then. :-) I'm not entirely clear as to your data model, though. Are Discography, Musicians, and Schedule all lists of all musicians on file, just showing different data? Are they searchable/sortable?
Thank you so much for your detailed response. It was a great help for thinking process, while I realized I should had mentioned an example.
Say, I have my own show the day after tomorrow. Both vibraphone player and the bass player are also performing for someone's jazz orchestra with me on Saturday. The guitar player for my show Friday have played for a few of my CDs, while both of us played for someone else's CD as well as major commercial shows.
See, we the jazz musicians go wherever calls us. This is why there will never be a band with steady members. My original band will never play again since the drummer has moved to NYC and touring all the time, and the pianist became a successful Verve record artist. In other words, the list of musicians who collaborate/collaborated with me is quite long. We have to grab who is best and available for the show date every time.
Example: I want to have next show announcement promoted on the front page. I maybe the leader, or I may be playing for someone's show. I want to list the musicians for the show. You click on one of the names. The new node of the musician opens, where all the recordings and the gigs that musician played with me get listed as well as the hyperlink to the musician's home page.
Boy, it sounds a lot of work required already.
My current site's, not Drupal but simple PHP partially done by myself, schedule section is done with 3 MySQL tables, one for the show date, one for each band I am currently working for, and one for the venues we often play. I only need to add the show to the date table, and the band hyperlink and the venue hyper link are automatically attached. I was hoping something similar to this data model to the musician list (tho I have to plan for this Schedule data model in Drupal 5.1 as well).
Do you think I should just create a site with simple pages first then improve later? I am kinda afraid I will never finish Drupal site if I am stuck like this on each steps.
Ah, OK, so you want a booking setup of sorts. You can certainly start with static pages if you want, but if you really want to use Drupal to its fullest potential it's important to go through this "think it through" step.
Here's my suggestion. See if you can follow. This is where Modern Drupal really shines. :-)
Musician node type: has name, website (link CCK field), etc. Also has a viewfield (CCK field) of a view that lists Show nodes that reference that musician.
Show node type: Has name, date (date CCK field) nodereference field to a Venue node, and a multi-value nodereference field to Musician nodes that lists the musicians playing there on that date.
Venue node type: Has a name, location (address CCK field), and other stuff.
Viewfield is a really weird module that lets you have a field on a node that is actually a the rendered version of a view. So that field "becomes" a list of Show nodes that musician has performed in. You can also have a nodereference field allow only nodes of a certain type, or offer a select box from, get this, a view. :-) (Views and CCK have a rather incestuous relationship, which is where so much of the power comes from.)
So now you can create lists of shows, lists of venues, lists of musicians, etc. That includes "the one earliest show happening after right now" for your front page, for instance.
I don't think you'd even need any custom code whatsoever for the above functionality. You may for your theme, depending how you want it to look, but the actual functionality is all there.
Does that help to see how to map out a data model in Drupal? As a homework exercise, consider how you'd then add a "Recording" node type that would be a CD of a given performance, and how you'd access it from Venues, Shows, and Musicians. That's why I said it's better to have a richer data model than you need, since you can then extend it like that.
Definitely have a read through the CCK and Views module categories on drupal.org. Even if you only use one or two of each, just seeing what is possible can often give you ideas for how to leverage it later.
Cheers.
Larry Garfield / 2007/05/17 / 01:43 AM wrote:
Definitely have a read through the CCK and Views module categories on drupal.org.
Hi Larry, Thank you so much for your detailed instructions. It sounds great, but I am too new to get it clicked. I have been trying to find CCK + Views tutorial but I haven't been able to find the one helps my needs. Same with general documentations. They are often for developers, which contains snippets, not GUI level How To. Is there any tip on how to search low level tutorials?
There is often better (or more easily findable) how-to info outside the Drupal.org site. Loads of tutorials, articles, videos, podcasts can be found elsewhere. Try just using Google for starters. Maybe there is a Boston area Drupal group that has a meetup?
On 5/18/07, A-NO-NE Music madflute@anonemusic.com wrote:
Larry Garfield / 2007/05/17 / 01:43 AM wrote:
Definitely have a read through the CCK and Views module categories on drupal.org.
Hi Larry, Thank you so much for your detailed instructions. It sounds great, but I am too new to get it clicked. I have been trying to find CCK + Views tutorial but I haven't been able to find the one helps my needs. Same with general documentations. They are often for developers, which contains snippets, not GUI level How To. Is there any tip on how to search low level tutorials?
--
- Hiro
Hiroaki Honshuku, A-NO-NE Music, Boston, MA http://a-no-ne.com http://anonemusic.com
-- [ Drupal support list | http://lists.drupal.org/ ]
Larry Garfield / 2007/05/17 / 01:43 AM wrote:
Musician node type: has name, website (link CCK field), etc. Also has a viewfield (CCK field) of a view that lists Show nodes that reference that musician.
Show node type: Has name, date (date CCK field) nodereference field to a Venue node, and a multi-value nodereference field to Musician nodes that lists the musicians playing there on that date.
Venue node type: Has a name, location (address CCK field), and other stuff.
Oh, oh, oh, these are tons of different modules you are talking about. Woa! I think I got it. Altho I haven't been able to locate Address CCK Module yet. I think I am getting on the track! Thank you!
On Friday May 18 2007 12:02 am, A-NO-NE Music wrote:
Larry Garfield / 2007/05/17 / 01:43 AM wrote:
Venue node type: Has a name, location (address CCK field), and other stuff.
Oh, oh, oh, these are tons of different modules you are talking about. Woa! I think I got it. Altho I haven't been able to locate Address CCK Module yet. I think I am getting on the track! Thank you!
http://drupal.org/project/cck_address which is in http://drupal.org/project/Modules/category/88
Also, although the Location module is not a CCK field module, you can add it to any content type: http://drupal.org/project/location
And if you combine it with the GMap module, you can get maps that list all users or nodes, as well as other functionality: http://drupal.org/project/gmap
There are still some minor issues with compatibility with each other and Drupal 5, but they are being worked on. It is kind of cool what is available and what can be done with them.
On Friday 18 May 2007, A-NO-NE Music wrote:
Larry Garfield / 2007/05/17 / 01:43 AM wrote:
Musician node type: has name, website (link CCK field), etc. Also has a viewfield (CCK field) of a view that lists Show nodes that reference that musician.
Show node type: Has name, date (date CCK field) nodereference field to a Venue node, and a multi-value nodereference field to Musician nodes that lists the musicians playing there on that date.
Venue node type: Has a name, location (address CCK field), and other stuff.
Oh, oh, oh, these are tons of different modules you are talking about. Woa! I think I got it. Altho I haven't been able to locate Address CCK Module yet. I think I am getting on the track! Thank you!
Yep. One of the key features of CCK is that you can cherry pick which field types you want installed. It comes with a half-dozen or so basic field types, but the real power comes from adding things like imagefield, date, viewfield, etc., which you download separately. Have a look through the CCK module category. There's lots of cool stuff there.
Hi, Just so i get everything right, because i still haven't gotten the hang of CCK, but, those extra modules you download, do you put them inside the cck folder or outside it? In other words i guess i wonder how Cck knows the other fields are there? /Krister
Larry Garfield wrote:
On Friday 18 May 2007, A-NO-NE Music wrote:
Larry Garfield / 2007/05/17 / 01:43 AM wrote:
Musician node type: has name, website (link CCK field), etc. Also has a viewfield (CCK field) of a view that lists Show nodes that reference that musician.
Show node type: Has name, date (date CCK field) nodereference field to a Venue node, and a multi-value nodereference field to Musician nodes that lists the musicians playing there on that date.
Venue node type: Has a name, location (address CCK field), and other stuff.
Oh, oh, oh, these are tons of different modules you are talking about. Woa! I think I got it. Altho I haven't been able to locate Address CCK Module yet. I think I am getting on the track! Thank you!
Yep. One of the key features of CCK is that you can cherry pick which field types you want installed. It comes with a half-dozen or so basic field types, but the real power comes from adding things like imagefield, date, viewfield, etc., which you download separately. Have a look through the CCK module category. There's lots of cool stuff there.
No, you install them under your usual /modules folder (you do use sites/all/modules and not /modules, right ? keeps your additional modules separated from core modules : easier updates later on :-) ).
CCK knows they exist because they define the functions ('hooks') CCK expects.
Krister Ekstrom a ecrit le 19/05/2007 10:07:
Hi, Just so i get everything right, because i still haven't gotten the hang of CCK, but, those extra modules you download, do you put them inside the cck folder or outside it? In other words i guess i wonder how Cck knows the other fields are there? /Krister
Larry Garfield / 2007/05/17 / 01:43 AM wrote:
Musician node type: has name, website (link CCK field), etc. Also has a viewfield (CCK field) of a view that lists Show nodes that reference that musician.
While I was doing this, I encountered a problem. I created a image field for the picture next to the name of the musician. When I go to create Musician Content, the image field only let you upload the image but it is already in the library because I have used it before somewhere else. Uploading again will duplicate it. I know I am missing something, but I can't figure this out yet. Any help would be appreciate it.
By the way, do I want to create Categories for Musician, Venue, and Show, or Reference Nodes between them will render Categories unnecessary?
On Friday 18 May 2007, A-NO-NE Music wrote:
Larry Garfield / 2007/05/17 / 01:43 AM wrote:
Musician node type: has name, website (link CCK field), etc. Also has a viewfield (CCK field) of a view that lists Show nodes that reference that musician.
While I was doing this, I encountered a problem. I created a image field for the picture next to the name of the musician. When I go to create Musician Content, the image field only let you upload the image but it is already in the library because I have used it before somewhere else. Uploading again will duplicate it. I know I am missing something, but I can't figure this out yet. Any help would be appreciate it.
If you don't want to duplicate the actual jpg file, consider image-as-node and then using a nodereference field to pick the image. There is an image.module that is very popular but also rather old, and has a few issues. Another option is to create a custom CCK node type, disable the body on it, and add just one imagefield to it. Voila, an image node type. :-) The downside here is that you're then loading more nodes on a page, so your theming could get more complex and it could have an adverse impact on performance. (Loading a node is ~4-8 queries or so on most sites.)
By the way, do I want to create Categories for Musician, Venue, and Show, or Reference Nodes between them will render Categories unnecessary?
Each node type is a type of entity. A category/taxonomy helps to classify the same sort of entity. So for instance "client" is a node type, while "paid" and "pro-bono" would be categories of client. "Album" is a node type, while jazz, rock, and disco are taxonomy terms in the "genre" vocabulary and "indy" or "big evil faceless corp" are taxonomy terms in the "contract type" vocabulary. :-)
When you want something to be a node type vs. a category depends on your use case. Bear in mind that a node can only ever have one node type, while it can have many associated taxonomy terms (tags) in multiple vocabularies simultaneously, and vocabularies can apply to multiple node types.
Thank you so much to Larry, I have moved forward quite a few steps.
Each node type is a type of entity. A category/taxonomy helps to classify the same sort of entity.
Understood. So, I created a Vocabulary: About (for now), which contains terms like Schedule and Discography, and tried to create a View to list only the titles of the nodes with terms as header but to no avail. Since both Schedule and Discography are Views, I thought I do: Page > List/Table View Field > Node Title Filter > Terms for About
I get nothing but Empty Text I created. Appreciate any help.
The thing I try to do the most is to separate the content out as much as possible. Keep things as "logical" as you can so that you can be flexible with how to use it. The problem arises when you want to start making relations between all of the different node types.
But you are definitely on the right path.
One thing that Larry mentioned about the discography can get tricky. If you seperate out the Discography into individual nodes, you might run into trouble just showing "Artist 1's" discography in one list.
This is a great solution but not very flexible.
-----Original Message----- From: support-bounces@drupal.org on behalf of Larry Garfield Sent: Wed 5/16/2007 10:56 PM To: support@drupal.org Subject: Re: [support] Newbee: How should I plan this?
On Wednesday 16 May 2007, A-NO-NE Music wrote:
I am still far from being comfortable with Drupal. Here is a problem case I need to solve.
I have huge list of musicians who have played for my past gigs and recordings. Many of them has their own website. Some of them will be listed for future shows.
I would like to create 3 sections, Discography, Musicians, and Schedule, where I want to call names from the list of musicians along with its hyperlink for their site.
I've got CCK and View, but I am not certain how I should plan this. Any comment would be appreciated.
You're already on the right track, then. :-) I'm not entirely clear as to your data model, though. Are Discography, Musicians, and Schedule all lists of all musicians on file, just showing different data? Are they searchable/sortable?
I'd defintely start with a Musician node type (or Artist, or whatever). That contains all the data about a single musician. Try to figure out what data on them will be category-like in nature and which is "part of" the musician. For instance, web site and number of people in the band are "part of" the musician entity. For those, use CCK fields. Whether their music type is rock, jazz, or disco would be a category-style bit of data. For that, use a taxonomy vocabulary called "Music style" with possible terms rock, jazz, and disco.
From there, you can create lists of musicians using Views by whatever
attributes you want. Eg, all musicians who play jazz, name and web site. All musicians with more than 3 people, grouped by their music type. Etc.
For Discography, there's lots of ways you can do that. You could have an "albums" field on a musician node that just lists album titles. Alternatively, you could have an Album node type that has a nodereference field that points to the musician node responsible for it (as well as year, label, who did backup vocals, etc.). That gives you the ability to create lists (Views) of album nodes, too, with links to their musician, grouped by musician, etc. I'm sure you can think of lots of other cool things to do with that sort of data.
You may or may not want to go this route directly, depending on what it is you're lookig to display, but hopefully the above gives you an idea of how to go about designing your data model "the Drupal Way". I would definitely advise erring on the side of a richer data model that you're not using rathern than a simple one that you may outgrow. You can certainly make headaches for yourself either way, but IME it's better to have too many options than too few.
Cheers.
-
A-NO-NE Music -
Jason Flatt -
Jean Gazis -
Krister Ekstrom -
Larry Garfield -
Mike Bishop -
Yves Chedemois