Symphony.

Nils, very nice to see that you've taken the initiative again on something so important. What you're doing seems a natural progression of the Associations UI, something I had been thinking about without time to dedicate on. The couple of weeks I've been away seem I seem to have missed out on the whole discussion & contributions but very good to see that the project has been funded by the community.

Just wanted to add my gratitude for those that funded this - it's a fantastic idea and something I'm personally really looking forward to using. I've only just become aware of it having been out of the Symphony loop for a few months.

I'm hoping to use it on a big project that's looming - and I was a little disheartened when I saw that neither Plus or Subsection were working with 2.4 - and I echo the original points that although these extensions are fantastic - they can be pretty overcomplicated - so this is all very positive. Symphony provides such a brilliant content framework but this is, IMO, the last piece of the puzzle to 'crack'. It could potentially allow for tagging and taxonomy tools that could rival WordPress's (one of their few strong points).

How is development going? I'd be keen to use this within the next few weeks - but I'm not sure if that's too optimistic… I see the repo's in place, I'll have a play later this evening assuming it;s usable!

The Selector UI is feature-complete and ready to test (you'll need the latest core from integration and Association Field instead of SBL). Editor and Output are next. The final versions of all extensions will not be ready "within the next few weeks" but we'll move into the beta and release candidate circles soon.

Excellent, thanks for the update! Appreciate my need is badly timed :)

Now that I'm aware of this project I'm very hesitant to start development using an older version of Symphony (with SBL+). How stable do you think the integration branch with this extension will be? I'm guessing the advise would be to not use it on a production site…

Dilema!

No comment :D

Sensible response :)

I'd wait for Association UI. Even I don't want to update SBL+ because Associations is under development.

Got a project that can't wait? Well ... oops! You'll have to live on the edge and test Associations while developing your project :)

Or you can use the classic SBL and upon Associations release, get dirty and update MySQL tables accordingly. I expect it won't be very hard.

Association Field is a direct fork of SBL so the only thing you'll have to change are the database table names and a few strings. No structural column changes needed.

Association Field is a direct fork of SBL so the only thing you'll have to change are the database table names and a few strings. No structural column changes needed.

Interesting. In which case it's quite tempting to use the vanilla SBL to start. The primary use of the extension in this project will be for 'category' type stuff, I just need a way for users to easily create new 'categories' from within the entry itself (basic use case) - so during development having it as a standard dynamic SBL will probably be fine if I can swap it over later.

Just a short shout-out to everyone who would like to have donated but missed out - it's not too late! We are actually still accepting donations to support the further development. Every bit is appreciated. :)

First beta versions

Over the last days, we released the first two beta version:

• https://github.com/hananils/association_ui_selector/releases/tag/1.0.0beta
• https://github.com/hananils/association_output/releases/tag/1.0.0beta

In order to test those two out, you'll need the following additional things:

• https://github.com/symphonists/association_field/releases/tag/0.5.3
• https://github.com/symphonycms/symphony-2/tree/integration
  (future Symphony 2.5.0)

Association UI Editor will follow soon – this is the most complex extension.
Thanks again for your support!

Hey Nils,
Made a quick setup and it seems to work good!
Am i right that the select box calls the values a-synchronic?
Does this mean it would load the entry page fast even if there are like 10.000 relations?
How you think this would preform with big data, compared to the regular select-box(link), which loads all association in the dom on page load, am i right?

Tested with a section holding 100,000 entries, works like a charm Cremol!

^^ This is good to know, as I've seen issues with SBL+ and SSM when it comes to mixed content (i.e. images) and a large number of entries!

This would indeed be very useful for relations with lots of entries!
I guess it would have no impact on loading the section entry while the loading starts only when entering the search field? which would be very nice!
Haven't found this functionality yet in existing relation fields (extensions)... so this feature would be very welcome.

Selector starts with the items already in the markup:

• existing items
• additional items up to the limit specified in the field settings

As soon as you start to search, results are fetched asynchronously.

There is one special case though: if you set the item limit in the field settings to 0, Selector will fetch the full list of entries from the associated section as soon as the DOM is ready. In this case, no additional lookups are made while searching.

Tested with a section holding 100,000 entries, works like a charm Cremol!

Thanks Andrew, that's good to know.

Hi Nils,

Slightly off topic but this interests me, hopefully you can explain briefly how the limit field works, I've often wondered!

So in this case all it defines is how many results are pre-fetched, but doesn't restrict the total number of results the field's able to grab? This makes sense, good to know.

Is this similar with SSM etc.?

I never quite know what to set that number at whether it be for the SBL, SBL+ or SSM, et al. because why would you ever want anything less than all of the results (at least when it's not datasource controlled and therefore just an arbitrary selection)?

Even with the Association field, wouldn't there generally be a 'good' number to use in all cases, a sweet-spot that balances the load of the initial query with the need for subsequent queries?

The limit is only there for performance reasons. If you have a section with 1.000.000 entries, you don't want to output all those entries in the markup: it just takes too long to generate the markup on the server and to display it in the browser.

The more you type in the search field, the better your results. So if you've set a limit of 20, you will get quite decent results plus good performance.

Hi Nils, sorry I understood that from your last response, I was more interested in the general intention of the limit field. As it seems that it could just be set to 20 programatically and not given as a user option. Under what case would you provide a different number? Would increasing it improve the accuracy of results, and in what way? And how does this compare with other fields that use the limit?

I only tend to interact with it for the SBL, and then just stick a load of 9's in it, as why would I want anything less than all the results? As even if I wanted to improve performance how would the SBL know which ones I wanted to include?

Would increasing it improve the accuracy of results, and in what way?

It completely depends on your data:

• If you have a product catalogue with article numbers that only defer by a single character, you'll most likely not get any good results with a lower limit like 20.
• If you've got a section with the letters of the alphabet, a limit of 1 will be sufficient to get the proper result because each letter only exists once. (It's a stupid example, but I guess you get what I mean.)

And how does this compare with other fields that use the limit?

Which other fields?