Search

Release candidates will follow soon, if no major bugs are found. All extensions require Symphony 2.5 (which is currently in beta as well).

What is the estimate that Symphony 2.5 is out of beta?

I also think there's a use case for both approaches.
I use select box link and the core association panel as much as possible.
Especially lately since subsection-manager has been deprecated.
I have to agree this is the right way to do it.
But looking at a client's perspective it's less intuitive then Nil's approach.

Regardless of the approach, i find the a-synchonicly autocomplete on the select box a big plus, especially for big data.

The reason i suggested to have Nil's association extension in the core is not per-sé for myself.
But i think this approach is more intuitive and easier to set-up for symphony newcomers, cause it doesn't involve data-source chaining, which i think is a concept quit hard to grasp for beginners.

Also the association extension for me is perfect for e.g. small to medium associations like a photo gallery and super easy to use for clients.

So maybe it's not a good idea to put this in the core (especially after reading John's thoughts on this).
But i would see no problem having these extensions side by side.

For me personally i would use the core associations for big sets of relations and Nil's extension for things like photo-galleries to give the client a nice user experience...

Yeah but the problem I have is that if effort were attached to a UI extension for the drawer, everything that the new Field does would be able to be done with the Drawer.

You would have an associating field in the child section, and from your parent entry, you would use the drawer, with a nice UI to create/edit/attach child entries.

This is what I'm annoyed at. If someone doesn't do this to show the capabilities, then how is anyone supposed to be able to learn and do it from the 'correct' perspective? This is why I thought, finally, Nils is taking the bait and building on top of the drawer work we did, only to find the same old backwards approach being used.

The reason I did the work was to put the building blocks in place for this style of UI (which is lovely to use by the way, I'm not trashing that) to be applied in the correct parent -> child direction.

Also, it's not about Symphony getting it fundamentally wrong in the beginning, it is correct. It's the UI that always lacked, not the actual linking.

If people actually read my research and notes, they'd understand. It just feels like I wasted my time really.

Obviously, If I had the time and knowledge about the current Symphony UI, I would prove it myself, but I don't. That's why I expected the core UI lead to do it, and it hasn't happened.

John, that post is insulting and inappropriate.

How is that insulting and inappropriate? I said your work is lovely to use, I said that the building blocks were in place to do it with the drawer, but that I think the wrong approach was taken.

I don't understand what is insulting there?

I don’t think there is a right or wrong here. It always depends on the the way a site works. Sometimes the drawer approach works best, sometimes an inline approach works better. Why shouldn’t both live in peaceful coexistence?

Ouch, stop bitching awesome guys. As Brendo and Cremol [edit] and Animaux says there are more ways. Both got valid points and both got more efforts points if it is in development of our favorite cms/framework.

I like the intuitive way Nils made those extensions but when I read this thread again and again (to understand what it's all about) I finally mentioned what already was accomplished within the drawer.

Kudos for both of you

I would really love to hear profound insights on John's main points, but nobody answered these, at least not precisely.

  1. In database design, is it the only "correct" way to link children to parents?

    (I really like this way of thinking, but it took me a very long time. I myself have built "association workflows" using the SBL field, but I don't know anything about database design. So this question is serious.)

  2. Has Nils indeed done it the other way 'round, "internally" (you know, "inner workings")?

    (I am sorry, but I haven't found the time to look at Nils' work.)

  3. So, is Nils' work really "trashing" John's engagement on associations?

    (And if yes, does it boil down to a simple disagreement on question #1? I couldn't think of any other reason, to be honest.)

In database design, is it the only "correct" way to link children to parents?

Children typically hold the reference to their parents, not the other way around, e.g. one to one relations. Let's say you have a bunch of users and mail addresses, where the mail address is a unique property of a user. Mail then references it's user by the user's id. The mail address has a so called (inverse) "belongs to" relation, because it's a property of "User" where the User has a "has one" relation, because the address is its property.

select * from Users where id =1    
select * from Mail where user_id = 1

Same for one to may relations, e.g. Posts and Comments, where one comments reference one post.

Having many to many relations the picture shifts slightly since you'll need to introduce a third player called a pivot which is referencing both parties, e.g. http://stackoverflow.com/questions/2492184/many-to-many-relations-in-rdbms-databases

Short answer: We didn't change the way associations are stored. We just worked on their visual representation in the interface.

Longer answer:

1. In database design, is it the only "correct" way to link children to parents?

Symphony already allows association of all kinds, many to many, one to many. Just replace „children“ and „parents“ with „left“ and „right“. In the early days of 2.0, the interface only responded to one kind of relationship but that was fixed by John when we worked on Symphony 2.3. This was an interface issue, not primarily a storage one.

Symphony works as it should – no changes here, no disagreement here.

2. Has Nils indeed done it the other way 'round, "internally" (you know, "inner workings")?


Symphony always stores associations in a separate table and we didn’t change this. We actually didn’t touch the technical implementation of association creation at all. What we did was to introduce the concept of association interfaces bases on Symphony providers. It allows extension developers to add interfaces to view and edit associations. Additionally, we added methods to attach these interfaces to associations on the field level.

And I think this is were the disagreement begins, because Symphony itself provides default interfaces on the section level: there are links in the index tables and we have association summaries in the drawer.

So the question is: are associations field or section based? It’s a bit like the chicken and the egg problem. Looking at the way associations are stored, it’s both: you need the section for the general connections and the field for the content references and the output.

The interfaces we created are field-based: we updated Select Box Link to make use of interfaces. This allows us to unify all existing associative fields in one field in the long run, because Select Box Link is now able to display whatever visual interface you need (Subsection Manager style, Select Box Link Plus style etc.). To reflect this unification and to get a consistent naming scheme, SBL was forked and rebranded Association Field in agreement with Brendan.

3. So, is Nils' work really "trashing" John's engagement on associations?

I can’t think of any reason why. The interface concept we created is abstract and indifferent: interfaces are bound to the association itself so they can be used to either provide an UI in the field or in the drawer. It’s a decision of the designer whether he hooks into the markup of the one or the other. None of the given core functions were impaired.

I think the main disagreement is about the fact that – with our interfaces – we did not enhance the drawer but worked on the field. But I think this is perfectly fine, because it’s one of the needed components in most people’s workflows. The other is the summary provided in the drawer.

And now for something completely different:

Releases:

Version 1.0.0 is out for all three extensions.

The other is the summary provided in the drawer.

Just to point out the difference:

  • Associations on the field level have a logical order: they are part of the field and content flow.
  • Associations in the drawer offer a grouped view of relationships: they are not part of the flow. There are fields on the one side and associations on the other.

Both concepts have valid use-cases and Symphony supports both.

@iwyg, @Nils: Thank you very much for these explanations. Hmmm. I will have to find the time and test these extensions in order to better understand @designermonkey's (serious) concerns.

@Nils & @designermonkey, didn't have time to really test and understand how this works. I certainly to get in theory John's point that in database design you always link the children to the parent (ie in standard stuff you'd have a field in the child table linking to it's parent) however from a UI perspective this doesn't always make sense for the clients - and I thought Associations was a great way to fix this problem, providing a UI keeping the database structures linked properly.

My understanding of SSM being deprecated was that the child id's were linked in the parent section. Which is according to a database design perspective incorrect. Having said that - since Symphony uses external tables, which would be equivalent to the the Many to Many database model, if set up properly I don't think it could be a major issue. Having said that I didn't delve into the code and didn't try it yet.

My understanding of SSM being deprecated was that the child id's were linked in the parent section. Which is according to a database design perspective incorrect.

That's correct.

Select Box Link was always right from a database point of view, Subsection Manager was not. From an UI perspective, both extensions were wrong because they only allowed a single direction of associations – just looking from different perspectives.

The idea of the association interfaces is to allow different interfaces with different perspectives. But the chosen UI perspective is independend of the way associations are stored. And this is only possible based on John's work on the core associations.

I haven't said that anyone has trashed my work, the work was me and Nils anyway, so I won't take credit there. The thing that has upset me is the research I did pointed to a flaw in the communities understanding of how relationships work, not relationships themselves.

This isn't the community's fault though, it's been propagated by a lack of direction to fix it at a UI level. @michael-e, if I remember right (and I do) you alluded to this in Cologne.

You can indeed link from parent to child in a database for a one to one, but it is ill advised as what happens if you need to make it a one to many relationship? You need to move the ID reference, or association to the child table.

The same goes for Symphony. You, as a designer/developer/awesome Symphonian, are building a pseudo-database with clever fields, so understanding database logic is a must, and we as a community of core devs need to propagate the 'right' way of doing it from a database point of view, or we are doing our users a dis-service.

I have no problem with Nils work, other than it shouldn't be stylising the field, rather the drawer. I was of the distinct understanding that it was to be done on the drawer. The field is just a physical link, and needs to be UI-dumb. It just knocked me back a bit to see it not done that way.

I have tried to apologise privately, even when I don't know what I've said that is bad.

Where do we go from here? Well, I will be taking Nils great code, and adding the ability for it to display on the drawer too, as I still firmly believe it is a must for us to have this.

Like I said, the issue is with the core UI propagating an incorrect understanding of relationships.

If we really want a link from the parent at a field level, then we should have a 'recieving' field added to the parent, like the Bi-Link firld used to do, but that concept was flawed massively. The drawer is the right way forward as Associations are not field based, but section+entry based.

I would love to do away with linking field altogether and have a separate area of the admin to handle associations, but that is a pipe dream I fear.

Anyway, I have no bad will to anyone, I just want this done right once and for all.

@designermonkey - I certainly agree that in theory releationships are section based rather then field based. And would certainly be nice to have the same UI in a drawer functionality.

That is, from a database design perspective if I want my blog to have multiple images, I should add a relationship from my images section to the blog section. However it's not practical to add images and link each to the blog, but we do the other way around in terms of ui - add the image to the blog (SSM way)

Is that what you're trying to get at?

Exactly.

You shouldn't be using the field to physically perform the link. You should be in your parent entry, your 'Blog' and use a UI to add images to it in your 'Images' section. That UI is the associations drawer, which is why we added a very basic one.

It's not just a 'reference' to the associations, it's where the associations should all be performed from.

The associations drawer in the child 'Images' section, that is a reference, and is there so theoretically (with a bit of UI work) you can add your current entry 'Image' to another parent entry 'Blog' if you wished to.

I have tried to apologise privately, even when I don't know what I've said that is bad.

And a reply is on its way. All good.

I'm one of the Symphonians who likes to understand what is under the hood. Though I'm more the designer/front-end guy than a back-end developer.

In the example given: the right (or maybe most direct/short) way should be that the image stores all the ids of blog entries where it is used.

With the association field there is an extra holder who stores both the entry id and the id(s) of the image(s). That way it is an additional link in the chain.

So the field shouldn't be a real field but more a symbolic link to the parent (in this example the image).

Do I finally understand this discussion correctly?

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details