Symphony.

This is one for Alistair or Rowan:

Is the concept of Section Associations still current? Could you explain quite what its purpose is, please?

class.field has createSectionAssociation() and removeSectionAssociation() methods, which are used by Select Box and Select Box Link fields.

I am presuming that this somehow manages the relationships between sections. The only time this data is queried is for the fetchAssociatedSections() method in a Section which is in turn used to build the attributes on <entry> elements. However other fields that make relationships (the Tag List, Bi-Link, Subsection Manager) do not add rows to the sym_section_associations table.

Is there a precedent to follow? Should all fields that construct relationships log these relationships into this table as best practice?

The reason I ask is that my Entity Diagram extension gets information about section relationships from the sym_section_associations table. But when fields don’t add the relationships into this table, there is no way to easily determine section relationships without resorting to sniffing individual field types and reading their own configurations.

More findings: Bi-Link, Subsection Manager et al. probably do not add their relationships using createSectionAssociation() since doing so means Symphony detects these and will always add the column to Publish tables of counts of related entries. Which isn’t always desired.

Which is a bit of a shame. Is there any other way I can easily see all relationships between sections? I hope so… because I have good stuff coming that relies on knowing all section relationships!

Good stuff, indeed. That looks very interesting, Nick.

More findings: Bi-Link, Subsection Manager et al. probably do not add their relationships using createSectionAssociation() since doing so means Symphony detects these and will always add the column to Publish tables of counts of related entries. Which isn’t always desired.

I tried to use the section associations when creating the first draft of Mediathek but I never fully understood the concept. It always seemed to do things the other way around as I thought it should.

My guess is that “section associations” is kind of a dead concept. The only two places I can see these formal relationships being used in the core is for:

• the count of entries in the related section on an <entry> element in Data Source XML
• the count of entries in the related section in the column that is appended to the “publish” table (table list of entries) in the backend

The only fields that actually use this “section associations” table (that I have found) are Select Box Link and Reference Link (which uses the SBL as its base).

The two places that this relationship is used can be replaced with per-field functionality:

• the addition of the counts on <entry> elements could be added at the point the appendFormattedElement method of a field is called (since it is passed the parent entry XML element)
• the addition of the counts in the backend should be done through the prepareTableValue for that field and not automatically by Symphony

This removed the need to maintain these section relationships in the database at all: the fields themselves (i.e. the SBL) adds the counts in the XML and the backend, rather than Symphony core. This has the added benefit that these count columns in the backends become both optional (by not showing the column in the table for that field) and orderable (they don’t have to appear as the last columns, they would honour the order of the field in the section).

Now, removing the section associations from the core doesn’t help me. In fact it’s the opposite, since I’m after a way to capture all of the relationships between sections without having to inspect each field and determine relationships based on the type of field used. The alternative is asking for all fields that create relationships to add these relationships to the section associations table. But this creates the unwanted visual counts/columns throughout.

So to make the core leaner I’m suggesting killing the concept entirely since at the moment it only seems to be used by the SBL, and the functionality can be moved into the SBL itself.

As for my own extension and its requirement for establishing all of the different relationships between extensions… I think I’ll need to resort to “field sniffing” and determine the relationships based on the way they’re stored in the database for each field type.

Wouldn’t it be possible to store all relations in the database but to source out the interface behaviour into the extensions?

Wouldn’t it be possible to store all relations in the database but to source out the interface behaviour into the extensions?

Good point. But I question the worth of storing the relationships if there’s no direct “need” in the core to do so. The way each field creates its relationships might be complex, perhaps not fitting into the existing parent/child section/field format the table prescribes.

I think you are right that there is no need for the core to store relations. But thinking of the way Symphony 2.1 will push functionalities into extensions I think there is a need for the core to offer a global system to handle relations (thinking of the release history Symphony has always be about content relations).

Maybe something quite simple would be sufficient like storing the ids of related section (saying that section A is related to section B) and adding another column where each extension or field can store background information.

Something important that’s usually necessary for relationships is dependencies - what happens if this object is moved or deleted? Usually it’s of the form: no action, cascade, nullify, deny (etc).

I’d love to see support for generic relationships provided by Symphony. I’d also like to see support for those relationships to be one-to-one, one-to-many or many-to-many - but I’ve outlined that idea before and it’s a big job for our nimble team of developers (and not in scope for 2.1 from my understanding). A change like this should mean fields like Bi-link, SubSection Manager and others would be entirely unnecessary as a section could potentially contain repeatable, non-sequential data elements (not arbitrary data, just more flexible data).

I’d love to see support for generic relationships provided by Symphony

Me too

Plus one — me.

As for me I actually use this feature (cascading_deletion) in my projects. I think this is very useful thing.

Using with:

• selectboxlinkfield

In db sym_sections_association change values:

• cascading_deletion - yes
• parent_section_field_id - NULL