Symphony.

Jonathan, please don't cross-post topics (here and Github) because it complicates discussions. We should keep issues on Github, in this case https://github.com/hananils/association_ui_selector/issues/18.

Thanks!

@Nils my apologies!

Beta!

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

Happy testing!

Wow, looking really good!
Very nice how the association pops up when clicking 'create new'!
Is this association also supposed to pop-up for editing?
Looks like it's not working or am i missing something?

Very nice that the association_output extension is separate and compatibel with other association fields as well!

Well done!

I have the extensions installed, and running 2.5 beta, yet nothing shows up, anywhere.

I don't know what I'm supposed to be looking for as there's three extensions, any guides on how to use this?

Have you selected an interface in the field settings, John?

Is this association also supposed to pop-up for editing?

Yes, it is. Have you pulled the latest code?

But I don't even see a field to look at settings. There is no field :( Like I say, there is nothing. At all.

Where would you like me to log it?

The fields are the core select boxes and tag lists when using dynamic options and Association Field: https://github.com/symphonists/association_field. The interfaces itself don't bundle any fields.

Martijn, I pushed a few commits today that should fix your problem.

Yeah now it's working!
Got nothing to add, but maybe a nice extra would be a keyboard shortcut for te escape key to close the popup...
As far as i'm concerned this one can go in the core, but maybe it's to early for that now :-)

Thumbs up!

Nils,

If we wanted to add the ability to drag drop a data attribute onto a textarea, how would we best approach this functionality? I'm thinking of how Mediatek/Sub section manager used to have an option to drag an image onto a textarea sort of thing.

I was thinking using the reflection field to create a data attribute that contained the markup I want.. 'similar to : data-content="{image:unique-reference}"' so that we can then use it with the Ninja technique to position content in the textarea.

Would this be an extension that build on top of the associationuiselector or if just by adding draggable or droppable properties etc.. would it just work?

Thoughts?

I just have to say Nils I have tested the latest beta extensions and they work beautifully. This work is immense and gives Symphony a great way forward when working with Associations. Have just worked on a Craft CMS project with another dev, there are many things I like about Craft, but the Associations interface, along with the speed of Symphony 2.5.0 make it a fearsome competitor, not to mention the numerous things that Symphony does that I've seen another CMS yet to do.

In any regard, I want to thank you and your wife for taking such care in developing such a powerful tool for the Symphony community

Can someone please post some visuals somewhere showing how this is supposed to work, as I get absolutely nothing.

I use an SBL, nothing, a Selectbox, nothing.

Also, @nils, I'm really confused as to why this has all been done around the SB rather than the SBL, as that is the dynamic, and what was already working, association field for Symphony. Also, it;s what we spent all that time working on the Associations interface to better. The next logical step from my perspective was to enhance the UI and functionality of the SBL. Why use the Selectbox instead?

John, I think you are just missing one piece in the puzzle:

There was a longer discussion about naming conventions for associative fields. It was consensus that Select Box Link is a confusing name in this context. After a longer chat with Brendan, we decided that it would be best to leave SBL as is and fork it to implement the needed changes for the association interfaces. The result is Association field – https://github.com/symphonists/association_field.

The idea is to deprecate SBL and replace it with Association field, providing an upgrader. It's exactly the same field with only the interfaces added.

Also, @nils, I'm really confused as to why this has all been done around the SB rather than the SBL, as that is the dynamic, and what was already working, association field for Symphony. Also, it;s what we spent all that time working on the Associations interface to better. The next logical step from my perspective was to enhance the UI and functionality of the SBL.

That's exactly what we did, it's just on the repo of Association field, the fork:

Why use the Selectbox instead?

It's not instead, it's an addition as soon as you use dynamic values in your select box fields (the UI only opens when you select a dynamic source).

So to write it down once:
Association Field == Select Box Link + association interfaces

Would this be an extension that build on top of the associationuiselector or if just by adding draggable or droppable properties etc.. would it just work?

If you need that functionality, I wouldn't bind it to the association interfaces. You could drop any field's content to a textarea, so something more abstract would offer more flexibility.

@Jonathan: Many thanks!

I'm understanding how this works and what is required, after a bumpy start in expectation, and I understand what it is expected to do, albeit I don't agree with it.

I'm going to make some requests on behalf of the project (Symphony) and will explain my reasoning, and then I'll explain my disagreements.

Can you change the names to Association Field UI: Editor, Association Field UI: Selector, and Association Field Output please?

My reasons are as follows :)

The work on the core associations, and providing an interface from a core perspective was only the beginning of how the core was to be adapted and extended to display those associations in the drawer panel. The panel has delegates so that an extension could (and should) be created to stylise these associations on a section + field level; For example, image links could have a gallery style associations drawer.

The new field and it's extras are an addition to this existing functionality, and are not the core, so it makes sense to me for them not to be labelled as plainly as 'Association xxx' as they don't have any relation to the core's association interface; They relate to a field that uses the associations.

Now for my disagreements.

I'm a little taken aback when I use this to realise that, yet again, the order of association is incorrectly understood here. The reason I spent such a long time trying to get the core working right was to prove once and for all with a proper working interface, that associations are parents with children. In database modelling, the child is always associated to the parent and not the other way around. Doing it the other way around is not correct.

The issue always was said to me that 'we want to be able to create new attached entries.' so I did this. I was told, 'we can link to entries, and multiple entries, but we can't see them nicely' so I did this (with your help Nils). I did this utilising and expanding on core functionality, and using a field to render the connection, all without actually modifying the core's functioning associations, that have always worked the right way around.

I'm not trying to tell anyone here that they are wrong btw, I'm just trying to clear this up once and for all, as to be honest this is really getting to me now.

The new Association UIs are completely ignoring all this hard work and effort by working associations the wrong way round. I was expecting this project to come up with something marvellous for the drawer interface that we painstakingly worked on, yet it doesn't. It just goes back to the field. This is the reason I was so confused and didn't think I saw anything at all.

The point was that the field should be ignorant, and the drawer was supposed to take over. The field should be hidden on association pre-population, and the drawer was supposed to be the UI. The field is just the simple connector, and the drawer is the UI.

As a community lead who has put a hell of a lot of time into researching things to make sure they are right, I feel somewhat let down by this. I know I personally didn't contribute financially, but I feel this is just going to drive the community back down the path of incorrectly visualising associations, the to be honest Nils, I thought we had agreed was a bad idea. This is why the Subsection Manager was agreed to be deprecated, as it did associations the wrong way around, and yet here we are with basically, conceptually, the same thing.

Why has this all been done on the field? Why has the community paid for work that doesn't even follow the core example and concept that we discussed and agreed, as it's supposed to be a community project?

I feel like I'm taking crazy pills here.

There is a use case for both John and I think Nils has done a great job about improving the use case that the majority of contributors are used to, which is creating associations from a field.

We currently have three extensions (minimum) that do this, Select Box Link, Reference Link and Subsection Manager. All of them have improved on the last, and the popularity of these extensions within the community one of the reasons why Hana and Nils has worked to create a new field to improve it yet again.

This field introduces the concept where the field UI can be swapped in and out to provide a better association interface for creation. It allows developers to create new UI's without having to rebuild the field extension from the ground up which is really exciting.

I think there's just been a misunderstanding about what this project was delivering. It is a new field that lays the groundwork for future enhancements, it does not extend the core Drawer functionality.

The core drawer UI could be extended upon, it's the reason we worked hard to introduce appropriate delegates, but it's a different undertaking and requires a different approach.

As you may already have imagined, John, I personally don’t think this project is doing anything „the wrong way around“ as well as I don’t think the interfaces are „incorrectly visualising“ associations.

Here is why.

When associations were implemented in Symphony in the early iterations of version 2.0, the core team made a conceptual mistake in our eyes: it opted for one single type of relationship (child to parent) and everything in the core supported this idea. But we know that associations are a complex matter with a wide range of applications and the work you did on the core association management fixed this issue. (The only aspects of the old concept that were left for compatibility reasons were the old names parent and child which should be replaced by something more generic like left and right in the long run. )

The drawer interface we’ve been working on together was meant to provide a default low level implementation to reflect associations in the entry view and to accompany the links in the index tables. Extensions were supposed to build upon that concept.

There might be a misunderstanding and disagreement between us two here, but for me personally that didn’t mean that everything should be handled inside the drawer. I actually always thought that there would be a need for a visualisation on the field level inside the main interface columns. The drawer adds an additional layer of abstraction and depending on the project that might work really well – or it doesn’t.

So what have we been doing in this project?

We have added interfaces to the core association management. These interfaces are neither bound to fields nor to drawers. They are attached to the association itself. So it depends on the interface designer, if he attaches his interface to the field or the drawer markup – the developer is completely free to choose where he wants to attach it. And that’s good because it offers flexibility.

Additionally, we have added methods to attach interfaces from within the field settings. This was a logical step because associations are created on a field level. Still, this doesn’t imply at all where the interfaces are placed in the interface – this is a free decision of the designer.

This concept gives us a way to handle all established interfaces – known from Select Box Link, Subsection Manager, Reference Link, Select Box Link Plus – on top of a single field. This is what Association Field is for. We are now able to swap visualisations as needed.

Can you change the names to Association Field UI: Editor, Association Field UI: Selector, and Association Field Output please?

This implies that the interfaces can only be used with Association Field, which is not correct. Firstly, they can be applied to any associative field, like the core select box or tag list fields. Secondly, they can easily be extended to be used with the drawer. So I think the naming is correct.

Why has the community paid for work that doesn't even follow the core example and concept that we discussed and agreed, as it's supposed to be a community project?

If you ask this question the other way around, it makes more sense: why did we build these extensions? Because people asked us to, because they thought they would be valuable additions to Symphony and their workflow. And we agreed for the reasons provided above.