3

I'm wondering what the EE design pattern, or best practice, is for cross-references.

I have a products channel that needs to be cross-referenced with a number of available colours, for instance.

Do I create an All Colours channel (contains all possible colours), and a Product Colours cross-reference channel, with relationships to the Products and All Colours channels? And let the user create the cross-reference by selecting the product and colour, then selecting the same product and another colour? Or is there a better way? (Please, please, tell me there's a better way.)

I'm open to writing add-ons. In fact, I'm researching that now. Not crazy about the hooks docs so far.

Thanks for your help.

Update: Thanks for the replies. You asked for more detail; so here it is.

Colours are just one of the cross-references I'm dealing with. The colours just have to point to a colour swatch (image) for display purposes. So a category could be used. Plus, with the category fieldtype add-on, we can make that category a required field.

But as I said, we have other cross-references to deal with. Each product is in a product type category (and yes, they're implemented as categories). Each product type has an image associated with it. So far, just like the colours. But then the user decided that some product types might have two images, and the user needed to select which one would be associated with each product.

This one is making my hair turn grey. If Playa is the answer here, I'm happy to get it. But what are these tags you speak of? I haven't heard of them before. When I did a search, I got Channel Entries Tag, which is just the template tag.

Thanks again.

2
  • 1
    The "tags" being referred to are even less robust than categories, so I doubt you'll want to use them in this case. But two examples would be the Tagger and Solspace Tag modules.
    – Alex Kendrick
    Commented Mar 16, 2013 at 0:46
  • Ah, so the tags don't come with EE out of the box. That explains why I haven't read about them. Thanks. Commented Mar 16, 2013 at 1:21

2 Answers 2

2

Bluedreamer is right, using tags for your colors might work great. But if extra data needs to be stored along with your colors, then storing them as fully-fledged entries is probably better. *

If you do need colors to be entries, you could just use the following set up:

Create two Channels: "Products" and "Colors"

Assuming a product has many colors:
In the Product Channel's custom field group create a custom field for the color relationship using Playa. Then, when editing a product entry you assign any colors (eg, create the relationships) using Playa's drop-panes mode. If you haven't tried it, Playa is very easy to use and has really flexible template tags.

If the product only ever has one color:
You could use the native Relationships field instead of Playa, but Playa also has a great single-select mode.

* As Travis pointed out in his comment on Bluedreamer's answer, Categories can hold extra data. So you could definitely consider using them for colors, but the interface and template tags for categories are more limiting than if you use Channel entries and Playa.

3

I think we'd need a little more information on the content structure and how you want to output the data.

Relationships are possible, but on first glance I'd probably look at using Tags for the colours.

You could use categories for colours, then assign relevent products to each relevent category - that would allow you to browse by colour, or pull in a list of colours into a product.

1
  • 2
    Categories can also have additional fields -- category fields -- so Alex's point, that you should make the colors "entries" if they have extra data, isn't necessarily a defining limitation. Categories are also easy to filter on, but they are trickier to manage than entries. Commented Mar 15, 2013 at 21:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.