views:

112

answers:

3

In my content tree, I have a tree of content items which represent cities. For each of those I want to have logical connections to a set of... let's say... National Parks that are within 2 hours driving distance. So a city will have multiple parks... and each set will be different... but of course a park will also be associated with more than one city.

What kind of Item and field setup works well for this sort of situation? I will be creating a custom renderer for these items, so I'm mostly concerned with how this should look in Sitecore to maximize ease of use and performance.

I'm using Sitecore 6.2.

(cross-posting from SDN, please forgive me... but I want to encourage more Sitecore community here on StackOverflow)

A: 

Are you going to be doing any lookups from park to city? For instance, would you need to say "find all the cities that are associated with a given park"? Or will it just be "find all the parks that are associated with a given city"? If you need to do the lookups in both directions, things get a little trickier and I would probably recommend using a search index. However, if your lookup is only in one direction, you could just use a treelist field to make associations from one item to many others.

From your description I'm not entirely sure if you actually need to use that many-to-many relationship, or if a one-to-many path is all you need?

aweber1
If he needs park to city he could just render from the other perspective? It is not likely that any other structure would be appropriate for a web interface.
Sky Sanders
Yes, we'll eventually do lookups in both directions. I'm not familiar with "search index". I guess you could look at is as multiple one-to-many... but isn't that the same thing?
Bryan
+1  A: 

For this kind of relationship you'll need the following structure:

Home

   Cities

       NY
       London
       Paris

   Parks

       Park1
       Park2
       Park3

The "City" template should have the Multilist type field called "Parks". The soulrce of this field should look to the root of Parks (Home > Parks). The same way the "Park" template has the Multilist field called "Cities". The source of this field should look to the root of Cities (Home > Cities).

In this way you'll be easily able to perform any kind of request.

Hope this helps.

Yan Sklyarenko
The only issue with this model is that you have to maintain associations in two places. For instance, if you add Park1 to a multilist (or better yet a treelist) field in NY, you also need to add NY to the multilist field within Park1. However, you could setup a save and delete handler like Gabriel suggested to make this process a little more "hands free".
aweber1
Thanks Yan, this is the best answer so far.
Bryan
+1  A: 

If the connection has to be both ways one way you could handle it is by adding some code to the save event.

Let's assume we have a City template with a field called "Related Parks", and a Park template with a "Related Cities" field.

Say we save a City item with two parks in the "Related Parks" field. On the save event we could retrieve the two parks and insert the current city being saved into the "Related Cities" field on those parks.

I am not necessarily saying this is the best way to go about it, just another option.

Gabriel Boys
How do I hook into the save event for a single item or template type? I couldn't figure out how to do that before, so adding a handler like this was problematic.
Bryan