I've got a few technical questions that I've come across while working with the D6 stuff - perhaps someone can help.
What is the best way to location enable a content type? After installing the location module it adds a Location section to a content type, but also its possible to add a Location field. What is the best approach? Any pros/cons?
When defining fields is it better to define specific fields for each content type, or define some general fields that are reused across several content types in the site, where that might make sense? I believe the latter may make theming a bit easier, but it also creates dependencies between content types in a way, which may make it harder to separate out as features?
What's the best set of steps to get tabs in organic groups? I've played with this for a bit but not got it working as yet...
Any help or suggestions is much appreciated :-)
paul
FYI, we're working on this dev site http://dev.transitionbelsize.org.uk/ (still early days!) and I've started separating most of this into Features, which can be found here: http://trac6.assembla.com/transition-initiatives-web/browser/transition_...
Comments
A bit of input
Hi, Paul. It's been a while since I've used the location module so I'm not the one to help you there. I'd have to install it to see exactly what you mean.
As for the content fields, I think you are referring to what's called data normalization. Generally, the goal is to store a unique piece of data only once and refer to it where needed. That makes maintenance easier and data integrity more solid. It is possible to bring this too far and that generally comes from experience. Also, with Drupal it's not easy to connect disparate pieces of data without being a programmer. Views pulls things together for display but there is no underlying framework that can propagate changes like there is in other systems. Make your schema design on paper then show it to an experienced developer and he/she will help you refine it.
And for tabs I'm not sure what you mean...to you mean http://drupal.org/project/tabs or something else?
Andre Angelantoni
Founder, PostPeakLiving.com
Node Location vs. Location CCK
In my experience, Node Location is best for making maps, either with or without Views. I have yet to successfully make a clickable map from Location CCK data. However, if you don't need to make a map, Location CCK is much easier to work with because you can drag and drop the field to the desired part of the node creation form (rather than messing around with numeric weights), rename it to fit each content type (rather than using or translating the default "Location" heading sitewide), and do all the other tricks that we've come to expect from CCK fields. Maybe the mapping issue has been resolved with the most recent update that just came out today -- it's worth a try. Undoubtedly Location CCK is more similar to the way locations will work in D7, so use it if you can.
Reuse fields among content types when the information being stored is the same. Don't make the mistake I've made of reusing a field when the information was similar but not the same. For example, I needed a field to indicate whether a building is wheelchair accessible, and a field to indicate whether a registrant for an event needs wheelchair access. Similar, not the same. Use a different field in that case so you don't have to extricate your data later when it turns out you shouldn't have reused the field. But when multiple content types have, say, a date when something occurs or a location where something takes place, go ahead and reuse the field.
Not sure what you mean about "tabs" in organic groups. Say more.
Bit further
I've upgraded Location and Gmap and have been able to plot points based on a CCK field on a map view, only problem now being that the Google Map background does not load, but that might be a separate problem.
With the fields question, here's a short example of what I meant. If say both an Event and Group type need an organiser field, it seems possible to have event_organiser and group_organiser fields separately, or a single common organiser field that is included in both types. Which is preferable? The former seems better to have distinct separate features (easier to save as Features) but maybe the latter is better for theming?
For Tabs yes I do mean the kind of thing that http://drupal.org/project/tabs is intended to provide, but given the sparse instructions I've not succeeded in making them work successfully. I wanted to have each Group page have a set of tabs on its page to be able to switch between parts of the groups, but maybe its adding too much complexity at this point.