Symphony.

@michael-e's approach combined with Nick Dunns 'Modal_Editing' extension provides a neat short term solution for me. Thanks for the tip Michael.

You are welcome. Big thanks to @nickdunn for creating the HTML Panel Field extension!

On another related ('scuse the pun) note, I'm looking at using sessions to temporarily store the child entries created from the parent while still creating a new parent entry, so that on save of the parent, the children can be saved with the relevant parent ID.

Just cos.

I'm not entirely sure if I understand on this bit. Would it not be possible to store a certain amount of relationship information with the field itself?

I don't believe that's the right approach. As it stands now, the data is stored correctly (although it could be improved) in the database. Sections are where relationships between one section and another should be defined. Fields identify the actual relationship between one entry and another.

To be perfectly honest, after all my looking and playing, all the info stored in the SBL is is the entry > entry IDs, the association data is held in the section_associations table, where it should be. The data is where it all should be IMO.

I agree here as well.

However, extrapolating entry relationships from any one field makes for a much more flexible section. For instance, changing a field that interprets the relationship becomes simple because it is only concerned with interpretation of data, not the data itself. Symphony would simply provide a method for a field to create that relationship in a new table that is related to the section and not the field.

I think @designermonkey has got this spot on. I've always added a link to the parent article from a comment how it should be. However when requiring users to complete a form automatically; it was always easier to use SSM for the simple fact that if they wanted an Image or two, they could just go ahead and upload. However I would rather have the Symphony Core able to handle many-to-many relationships as well. Which would mean all links stored in an intermediate table (nor in the parent nor in the child)

So If the logic makes sense in the SBL, we should be looking at User Interface alterations to make the creation of child entries possible through the main interface. So creating a new field which would not store anything but just create this interface could make sense... but then why not add an option in the Field in the Child Section (Can be created/edited by parent section?) wouldn't that achieve the very same aim?

PS. I also think that the sorting was a useful think in SSM not sure how that would come in the one-many relationships exactly. Most likely an intermediary field which adds the functionality, would be best.

Btw John another good Many to Many relationship would be this. An article can contain multiple images, and images can be used in multiple articles. (Eg I have a nice picture of the office, and when there is some news about the company I would stick in that picture, and maybe some other one)

Symphony would simply provide a method for a field to create that relationship in a new table that is related to the section and not the field.

@Lewis how would you define this? I could have two fields making a link to the same section, eg say I have a direct-message section. I can have a link from the Members section which refers to the Author, and the other which identifies the receiver. So the relationship in between sections is happening within the context of the field (author or receiver)

@ijy: When it comes to many-to-many relationships, there is often no need for an intermediate column, as that is already created in the background for the one-to-many relation. For example, imagine the classic books and authors sections, if you choose the author on the book entry, and you enable allow the selection of multiple entries, you have effectively created a many-to-many relation.

@creativedutchman @designermonkey That's essentially what I was getting at so if that's possible with the field settings then that satisfies that possibility. The associations table in the database provides a way to keep the relationship information out of either the parent or child table so that all works for me.

To be perfectly honest, after all my looking and playing, all the info stored in the SBL is is the entry > entry IDs, the association data is held in the section_associations table, where it should be. The data is where it all should be IMO.

On the whole I'd agree but just from the sense of exploring possibilities what if you wanted to place restrictions, rules, or filters on the relationship? For instance, what about the possibility of linking to two or three different sections (defining the scope)? Or adding rules so if linking to a section of books they must be in a particular category or added after a certain date? If you could set these parameters when adding the field to the section it could be useful. Those parameters would then build and run the query and present the returned results to the user in the relationship field to choose from. Even better (again, just exploring possibilities) how about making those returned results searchable and filterable at the time of creating the new entry. If that is all stored in the associations table then that's perfectly fine but I'm just throwing in the possibilities which could possibly alter the type of information stored so it's all considered before it's implemented. :)

On another related ('scuse the pun) note, I'm looking at using sessions to temporarily store the child entries created from the parent while still creating a new parent entry, so that on save of the parent, the children can be saved with the relevant parent ID.

Interesting. I think as the problem is refined the linking isn't too much of a problem either. The hardest part is the 'create new' option to save to another section—the bi-directional part of the relationship.

I might very well be mis-understanding or understating but can an add/create new button not link to an on-screen overlay/modal which presents a simple interface for that section? Grabbing the same fields presented when creating a new entry for that section and saving to the database as if it was just a normal section entry save? It seems the big problem is in not interrupting the workflow but having to go out of the publish page, into another section, create new entry there, then go back to parent entry, then add it. Providing an overlay interface would allow the user to stay on the entry page?

@Lewis how would you define this? I could have two fields making a link to the same section, eg say I have a direct-message section. I can have a link from the Members section which refers to the Author, and the other which identifies the receiver. So the relationship in between sections is happening within the context of the field (author or receiver)

No problem, the sym_section_associations would indicate the relationship and the id column would reference a look-up table sym_section_links_section-association-id where 'section-association-id' would be replace with the number in id column (similar to data entry tables).

The relationship fields would check for a link, add if it doesn't already exist, and then store display related data in its sym_entries_data_field-id table. The latter is where the different display requirements are met. Deleting a relationship field would not delete the relationships - just how they are displayed. Make sense?

For reference: displaying association stats and links within the drawer:

Discussion on Twitter: https://twitter.com/nilshoerrmann/status/288693175084781569

My idea would be to have this feature in the core (like the links in the index), leaving advanced interactions to extensions (adding new entries, delete existing ones, inline editing, changing the parent entry). I see this feature in both sections, the child and the parent one.

With this concept, it would be possible to uninstall Select Box Link and still see the existing associations in the backend (missing the option to add or remove links of course).

My idea would be to have this feature in the core (like the links in the index), leaving advanced interactions to extensions (adding new entries, delete existing ones, inline editing, changing the parent entry). I see this feature in both sections, the child and the parent one.

Agreed. Awesome drawer idea too!

As a post scriptum: my mockup is only visualising the associations stored by the core. It's not adding anything fancy – this should really be done by extensions.

For instance, changing a field that interprets the relationship becomes simple

Replaceable fields is already on the idea list for Brendan and Rowan, if I get your meaning right. One field of a certain type (relating) could easily be swapped for another of the same type.

sense of exploring possibilities what if you wanted to place restrictions, rules, or filters on the relationship?

Filtering is a big missing link for me, and the SBL, or at least an extending field does indeed need updating with that, but we need to get the big anomalies fixed first. It is on the list.

The hardest part is the 'create new' option to save to another section—the bi-directional part of the relationship.

This is where a session would work. Brendan likes the idea, so I will be progressing it.

on-screen overlay/modal

We want to avoid these. We have the Drawer concept (see Publish Filtering so far) and Nils has just shown me some in-drawer UI concepts for this, which look really good! (he's added them here since I started writing this).

Giel used a modal in SBL+ and while the concept was solid, it looked ugly and not 'Symphony' in my mind, so we would want to avoid it.

Some of the stuff being asked here is way too complicated for now, as this discussion always gets. Also some of what @ijy has asked, is also way too complicated (and already been addressed two or three times already, sorry) and is out of scope for getting this done in baby steps.

The proposal is in, Brendan has read it, as has Nils. I have to read Brendan's response tonight when I get home (and have a beer) and then make a start from his recommendations. Nils is prototyping UIs, and we will meet in the middle.

We need to pair back this discussion a little, I can understand everyones requirements, but like stated, baby steps are needed here to not balls this up.

I love Nils' work here, and it compliments my ideas and proposal, so we'll be moving this forward asap.

The discussion here got a great advance, so my thoughts maybe are useless, but still I'll share...

I have came across situations where both the SBL as SSM did not work perfectly for the needs of the project or clients.

For example in the case of SBL, a parent section that is nothing without the records section daughter. In a not practical solution, it was made a field "publish" by default "no" when the parent section is saved, then a link to the child section filtered with parent section id, add the child entrues and go back, then set publish filed to yes and re-save parent section.

With SSM there were two problems, the first is the confusion that the user had to administer a section inside another, while functioned independently in same time. That is, while editing the child section within the parent section, parent section should be locked, so there is the no risk of leaving something unsaved in either section. This can be solved with modal box. But from what I understand, modal boxes is something that will be avoided, which leaves me without idea. The other problem is the output of XML, there was no way of defining the filter characteristic while output childs inside parent DS.

In my understanding, the SBL field works pretty much good, it's so simple (I think this is one important point) that can be used in any relationship case although it leaves something to be desired as regards the UI workflow. What was suggested by Nils with the "Linked Entries" sounds great and very usefull. But still think there need to be a way to access (view/filter,create,edit,delete,sort,etc) the child section from inside parent entry, and lock parent entry while child is being manipulated. In the XML output I would not change anything.

Some of the stuff being asked here is way too complicated for now, as this discussion always gets. Also some of what @ijy has asked, is also way too complicated (and already been addressed two or three times already, sorry) and is out of scope for getting this done in baby steps.

No worries, they were mainly just points of consideration and possible needs for varying situations. It's always wise to consider future needs at the design phase as those could well alter the implementation and could later mean having to go back and undo things. If those things have been considered and wont affect the planned method of implementation on the baby steps then no problem at all. I'd say eventually for larger sites some form of filtering both at the time of administration and at the time of entry creation will be essential for larger sites from a usability and workflow point of view.

The drawer that Nils has proposed looks great and I'd agree that it is definitely more elegant and in keeping with the rest of the Symphony style. It would definitely be a benefit to the core in my opinion as would the new SBL field. Entries without relationships on any size of site are meaningless.

It sounds like I'm a conversation or three behind and don't want to slow you down so I look forward to seeing what you guys come up with. :)