Symphony.

Lately several questions, extensions and clever techniques have cropped up on the topic of section links, so I thought it might be useful to start a philosophical discussion.

My basic rule of thumb when working out section links is this:

• Entries are saved one at a time. Work out which order your entries will get saved in.
• Put the section link in the last entry's section.

I know that's completely trivial, but it's important to understand this constraint when designing how links should work.

By the way, don't think of a section link as a specific field type. It's really just a piece of information that two entries have in common, regardless of what field type(s) they're found in. (Also, "section link" is a somewhat misleading term. It links entries, and they don't need to come from different sections.)

The actual linking work is done in a data source. Information from entry A is used to form a query to get entry B. It doesn't matter what method is used to achieve this, if it happens then those two entries are linked. In S2, param output is one way to do this; sharing a URL parameter would be another way (where a field's handle in entry A is the same as another field's handle in entry B).

It seems to me that what I just described is the loosest possible definition of how entries can be linked. Expanding on this definition only adds restrictions, which I'm definitely open to, I just haven't thought of any good ones yet.

The problem with this definition of section links, however, is that it's very hard for Symphony to backwards-derive relationships from where they are formed in data sources. Section links are a by-product of how the developer uses Symphony, they are not a specific entity on their own, so Symphony is unable to use this information to streamline the workflow for creating multiple linked entries because it doesn't know where the links are.

To solve this, you can either ask the user to only use a special field type to create links, where this field type has its own built-in workflow streamlining solution, or you can ask the user to explicitly recreate the link graph in a way that Symphony understands and applies to achieve the same workflow streamlining effect.

There might be other options, but from the two above, I'm not quite sure which is better. I feel like better integration is needed, but at the same time I value modularity highly. The most pressing issue is that we need to figure out what the ideal workflow should actually look like (and this needs to cater for all of the many ways that section links can be used).

After some deep, cosmic reflection, we've realised that Symphony's most fundamental strength is its workflow, and it seems awkwardly imbalanced for development to be easy but publishing to be hard. One should not come at the expense of the other, and a recurring theme of Symphony's development has been our tendancy to like showing that you can often have your cake and eat it too.

I'll post some ideas shortly, but please feel free to comment, brainstorm, solve all my problems for me. I hope this thread might be helpful to future extension developers or core contributors.

Scott, you say:

• Entries are saved one at a time. Work out which order your entries will get saved in.
• Put the section link in the last entry's section.

This is why section links (or the Select Box Link field) work the way they do. This is fine if you want to link comments to entries, the latter naturally coming first. But in the past months I have come across some real world issues which showed the need for a more flexible approach.

• Indeed entries are saved one at a time, but the order of saving might not be always the same.

  Let's say you are linking movies to blog entries. Maybe you want to link a new movie, maybe an existing one. (Your movies section might be completely independant, driving dedicated pages of your website.) You will not know the author's workflow. You are simply defining a workflow for him according to technical restrictions.

• The section link (or whatever the name might be) should therefore allow for linking (and DS filtering) in either direction. The first - linking - is a matter of UI and workflow. The secong - filtering - might strongly influence your technical design (datasources, XSLT).

  Imagine you have linked movie entries to article entries in Symphony 2. You may filter your movies by the DS param output of the article section. Now try the other way round: By linking articles to movies, you might simply choose an existing movie while editing the article. (This workflow might be better or not.) But - at least at the moment you will not even be able to apply filtering to your movies DS. (This is a known bug.) Anyway you will find that filtering is applied differently depending on the direction of filtering.

So I am dreaming of something like this:

1. linking entries (or fields?) without any "master/slave" construction (which will always imply restrictions)
2. many to many relationships (of course)
3. a UI solution which allows for establishing the links in either section's entries (see 1.: no master/slave)
4. filtering in either direction (with the same UI and workflow) (see 1.)

Wouldn't this be great? Yes!

But is this possible?

Scott says:

After some deep, cosmic reflection, we've realised that Symphony's most fundamental strength is its workflow, and it seems awkwardly imbalanced for development to be easy but publishing to be hard. One should not come at the expense of the other, and a recurring theme of Symphony's development has been our tendancy to like showing that you can often have your cake and eat it too.

So it is possible! My dream will come true!

:-)

Maybe you want to link a new movie, maybe an existing one.

In the case of linking to a new movie (if the blog entry contained the field that linked to the movie), you'd have a 3-step process: create the blog entry, create the movie entry, then go back and edit the blog entry to add a link to the new movie. I think in most cases where this happens, this third step can be eliminated either by moving the section link field to the opposite section, or by changing the author's behaviour so that movie entries are always added before blog entries.

But this example does raise a point that I should have made clearer: entries must be saved one at a time, but that doesn't mean they can't be saved in a single request, this is just a current limitation of S2. Rowan's Sub Section extension works around this by sending multiple requests sequentially from JavaScript, but the same idea could be applied from the backend. No matter how it works, you still need the "attached" entries to capture some information (usually, the entry ID) from the "parent" entry, which is what I'm saying is the section link.

The section link (or whatever the name might be) should therefore allow for linking (and DS filtering) in either direction.

I don't consider links themselves to be one-way. If a link is just a piece of information that a set of linked entries has in common, then it's symmetric. In the case of the Select Box Link field, you could either param output Entry ID or the SBL field, depending on which direction you want to connect the link.

What is one-way is the interface for creating links. But only if that's how you set it up. Some examples where this is not the case:

• Add a tag list field to each section. Collect linked entries by param outputting and filtering by tags. (In S3, suggestion lists for tag list fields can be spread over multiple sections.)
• Create a "Links" section that contains two select box fields. In one, select the "from" entry, in the other select the "to" entry. Use a series of 3 data sources joined by param output to connect linked entries.
• You could also theoretically link entries by system date or author, which I'm pretty sure would be completely useless.

The consequence of this is that there's no good way to represent this in the interface. Just creating linked entries is only half the problem - you also need to be able to find entries by their links. In the tag list example, you'd want values in the tag list column on a section's overview table to (hyper)link to the other related section's overview table, but filtered by matching tags. But what if there are more than two sections linked by these tags? Which section should it link to?