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. -- - Hiro Hiroaki Honshuku, A-NO-NE Music, Boston, MA <http://a-no-ne.com> <http://anonemusic.com>

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>

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! -- - Hiro Hiroaki Honshuku, A-NO-NE Music, Boston, MA <http://a-no-ne.com> <http://anonemusic.com>

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. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

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

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. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

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. http://drupal.org/node/124446 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. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson -- [ Drupal support list | http://lists.drupal.org/ ]