My site already has over 500 nodes, most of which are events, so it looks like I'm heading toward thousands of nodes. Each event has a venue (using Address Fields) and many events share the same venue. For example, all of the events taking place at a library will have the same venue so the library's address is repeated for each event. Basically, I've been treating the database as a flat file, which is dumb.
The better solution would be to treat this as a relational database by storing the venues separately and linking to them.
I've come up with a solution but it's awfully heavy and it seems that there should be a better way. My solution was to create a taxonomy term for each location, link the taxonomy term to the event page, create a view for each event that pulls the two together, and create redirects from the event page to the event view (the redirects are necessary because the view doesn't handle repeating dates). It works but it seems that there has got to be a better, lighter solution.
Ideally, I'd have a little php that says "If there is a taxonomy term from the Venue Vocabulary, then display that data." It seems that this would be common but I haven't been successful yet finding a solution. I may just not know what to search for. I thought that the Entity API may help but I haven't found a solution there (or maybe I'm just not recognizing it).
One little potential snag is that each event includes a geomap to show the location of the event. Within the taxonomy terms, I can store an address and use geofield to geocode that address, but it doesn't look like the taxonomy terms will actually store a geomap. So, if I pull in the address and geocode from the taxonomy fields, I'll still need a way to generate the map (though I was able to do this using the views solution).
Any ideas?
I found a statement on a different website that says "Term references cannot be formatted as rendered terms. Although this seems like an oversight, there is no field formatter to display a taxonomy term in its rendered form inside of another node. This could easily be created, but again it emphasizes the different focus on how terms should be used." The author says that "taxonomy terms shouldn't be considered 'content'". If taxonomy terms aren't supposed to be used this way, then is there a different solution?
I've implemented the views solution on my local site. If you think there would be any advantage of seeing that solution, I'll dummy up the views solution on the live site so y'all could see it.
Thanks.
By the way, this will probably be our lightning round question. If there's any time left over ("yeah, right"), our next question will be "What tool do you use to check your site on the various browsers? Do you have PC's hanging around with all of the versions of IE?" I tried a free online tool by Adobe but that tool didn't render the OpenLayers accurately whereas the real IE browsers had no problem.
Debbie
Comments
The answer
For the benefit of anyone reading this, there are a number of modules that address this need for Drupal 7 in a much better manner than using taxonomies. The two dominant solutions at the moment seem to be "Relation" and "Entity Reference". "Entity Reference" is simpler but "Relation" may solve additional problems that I've been working around. So, I'm considering both.
[Update: While the Relation module is powerful (and fun), I couldn't find a way to display the fields from one node while rendering a related node (e.g., display the venue address while rendering the related event). It looks like the only way to do this at the moment is by using Views, which makes this solution too burdensome. So, I'm going to use the "Entity Reference" module.]