Symphony.

Scott:

I'm devoting my time to the section link replacement/simplification

What we talking about here? I have to admit that in the beginning I was skeptical of its implementation but I've since learned and realized its full potential. Is its replacement/simplification going to take away functionality?

It seems that the only dislike in confusion with the section link in 2 is having to do with images. Let's not let images be the only guide to how section links are implemented.

Section link as a field was confusing in the beginning, but now it totally makes sense. Take for instance the following screen capture; it's a section that is part of a shopping cart that I am working on for a project.

Firstly, courses has a section link to programs. I display this field as the first one since courses don't have a name per se, they are just different times/days for the program it is section linked to (imagine selling a T-shirt and having multiple sizes, colors available). Section links as fields, allow you to do this. Secondly, there is a students section that has a section link to courses (and a section called orders, by the way).

Now, I think the current implementation conveys these relationships quite well. Aren't these relationships amazing?

• Unlimited courses for each program.
• Determine how many students are enrolled in a class.
• Lookup students by orders.

These are just some of the relationships that come to mind that I plan on utilizing.

Brilliant. What say you?

I'm really liking the current implementation, and your example, Lewis, is a good case in point.

When I saw the "replacement/simplification" comment, my eyebrows were raised. I'm also wondering what's up the Symphony Team's collective sleeve.

Maybe I should have added the disclaimer that by "simplify" I mean only applying to the workflow and learning curve; we're not taking away any of the positives you mention, just trying to eliminate some problems with the section link and select box fields.

There are many moving parts to this problem, so I don't know how well I'll be able to explain it. Much of this is still up in the air too, so I'll give you a more detailed answer once the implementation is close to complete. The explanation of what changes might sound confusing, but the goal is for these changes to make system by itself much easier to learn, understand and remember.

S2b5 won't include the update in question, but this will hopefully be implemented by S2b6, in a way which will break compatibility with previous beta builds. We think the benefits will make it a worthwhile change.

1. Unable to post entries directly from section list

This is just an interface problem. You should be able to either (a) find the target entry first then create/view other entries linked to it or (b) directly create an entry in that section then choose which entry from a list to link it to.

What we want instead is for section link fields to display like a select box so that authors can choose which entry to link to, and change it if need be. But this leads to another problem.

2. Unlimited select box options

Select boxes become a problem when their list of items is growing and unconstrained. Our solution is to list N most recently modified items (entries should have both modified and created dates added by the system) and include provisions for searching for others. The algorithms and UI for this are tricky and will take us some time to get right.

3. Alternative methods for entry linking yields a steep learning curve

There's the "categories-style" select box field-based approach and "comments-style" section link approach, which places a lot of responsibility on the developer to choose the right one from the start because this can't be changed later. If there were only one field type intended for heavy-duty entry linking, which could work in whatever direction the developer desired, this would be preferable.

4. Select box fields are sub-par for entry linking

Edit: The following is not quite true; the speed difference between filtering
      by a param output ID or string value is, in most cases, insignificant.

Since they use strings rather than IDs, select box param output is less efficient to use as a filter than if dynamic option values represented the ID of the target section. If this change was implemented, there'd be no difference between select box fields and the revised section link interface described under #1. Using IDs would enable select box values to be linked to their related entry, with a column on that entry's section just like with section links currently.

A huge benefit to this would be many-to-many relationships, which aren't possible now with section links. But we're still evaluating whether the two field types can be merged or whether they should remain distinct.

Ask questions! Give suggestions! Nothing is set in stone just yet, but we're pretty confident this change will greatly simplify Symphonians' life, especially since linking entries across/within sections is one of (if not the) biggest focuses of S2. Even if I don't reply, I promise I will read them and take them into consideration with this change.

Thanks for the update, Scott. The list you've provided pretty much sums up the problems I had come up against with section links. I agree that a single field type would be preferable. The problem then is finding the right method or methods to find the entry to link to which will allow for many-to-many relationships.

I think the type of interface that works best for this is something like the Joyent Connector's tagging system, similar to what is currently being used for the tags field in Symphony. I like that the selected items are separated from the list, so that you don't need to scroll through a large list to find what you've selected.

If the list of available entry options becomes too long, it could become a scrollable list. Beyond a certain number, this list should be defined by a search field, displaying the best options similar to an auto-completion search such as what Yahoo! has been using recently.

I don't envy the challenge ahead of you.

Here's a thought: what if the method of listing available entries is left up to the developer. The type of field is then decided by which type of selection method the developer chooses to be most appropriate. More complex selection methods need not necessarily be in the core. These could be offered as extensions.

Here's what I propose: add a checkbox to each of the form elements that are able to list multiple entries:

• Text input (for both single or comma separated IDs)
• Tag list
• Select menu (single option)
• Select box (multiple options)
• Filtered select box (multiple options filtered by parameter)
• Basic Search (for extensive lists - offered in the core)
• Advanced Search (offered as an extension)
• Auto-completion Search (offered as an extension)

The checkbox would give you the option to use the form element as a text input for plain text or as a section link for entry id numbers. This, I think, would be the most flexible method, in keeping with Symphony's goal of giving the developer maximum flexibility.

I think the type of interface that works best for this is something like the Joyent Connector's tagging system

Yes, that's similar to what I was thinking, except each "tag" would also link to the correpsonding entry. There will be a source list displaying search results (or last modified by default) which can potentially come from multiple sections if the developer chooses ("dynamic options" is multi-selectable), hence the significant functionality gains from this change. There will be an upper limit imposed (25 perhaps, but can be changed in your config) and no pagination - instead you'd have to search again with a more specific query.

The other day I prototyped up a really simplistic solution just to demonstrate to Allen, but the more I think about it the more I realise that it's more complex than it sounds. One important consideration is that we don't want to introduce redundant complexity for ordinary simple select boxes, or ones with a small number of options.

Allen's example was that in a Symphony-based forum, if there were flame wars on multiple threads, he'd be able to write a single comment associated with each thread telling them all to pipe down. I think this usage would apply more to files and other non-linear data than conversation, but it really does open up the possibilities even wider.

what if the method of listing available entries is left up to the developer

So far there are already two types of views: ordinary select boxes and multi-select boxes, which will each be enhanced in different ways. Your idea for extendable views is really interesting, however the UI is by far the least decided-upon matter at present. Your more complex suggestions could probably be implemented as entirely separate field types, but extensibility is definitely something to consider.

The checkbox would give you the option to use the form element as a text input for plain text or as a section link for entry id numbers

You've identified the issue I was concerned about with strings vs IDs in param output. But I don't think this should be an option. Effectively, the developer shouldn't care what gets used behind the scenes, since everything will work the same way as it does now anyway, but Symphony should optimise by using IDs wherever possible, meaning anything that has a "source" (select box and tag list fields). I believe this would reduce the number of db queries on complex pages, although not significantly.

but Symphony should optimise by using IDs wherever possible

That brings up the issue of filtering data sources by section link data. I had hoped to be able to use section link filters based on client codes and project numbers. However, it doesn't appear that the data sources can be filtered by section link handle, but only by the ID number.

To have human readable URLs, it seems I need to build URL parameters such as /client/client-id/project/project-id/ so I can limit the entry data flowing into a front-end form.

I'd rather have URL parameters such as /client/project/milestone/task. Is it possible to use handles instead of IDs for filtering section link data?

The current build of Symphony can already handle this with DS param output. What you want to do is create a data source that filters by milestone and/or task (strings) and choose ID as the param output option.

So now, instead of grabbing from the URL Param $task, you grab it from the data source you just made: $ds-task.

In a system that is associated with IDs only, the above method would still work. Scott has suggested that URL Params are always converted to IDs as an intermediary step before any DS is filtered as an alternative. This way, the developers never need to work with IDs even though the system does exclusively.

I haven't explained that terribly well, but the point is we've got it covered :)

I think I finally got it. Thanks, Allen. It's working beautifully. Very powerful indeed.

i'm not really following this explanation. can anyone help me out a little bit more?

currently, i have a section that should filter by the variable $sub. This variable is set to filter a field that contains the type of information it is (so currently, I only have 3 different types).

In my DS, I've tried setting the Filter Results to a System ID and filtering by {$sub}. I've also set the Sorting and Limiting - Sort By as well asOutput Options - Parameter Output to System ID. However, in my xml, i don't get any sorted results. any help is much appreciated. thanks.

bauhouse:

Is it possible to use handles instead of IDs for filtering section link data?

A conversion has to happen anyway from URL handle to actual string value or ID, so which type it gets converted to doesn't make much of a difference. Now that I've thought about this some more, the performance difference between the two is negligible, and using strings instead has many benefits:

• Strings are more informative when it comes to debugging.
• Strings can translate between all field types. (With my proposed change, the developer would have to remember which filter types are compatible.)
• A ubiquitous format would enable an extension idea of Alistair's for field mapping/conversion.

I'm nearly convinced that IDs don't have to be used anywhere visible to the user, but I'll need to get Alistair's expert opinion before deciding.

So really this change is much less drastic than I made it out to be. By mostly improving the interface for select boxes (to make it tolerate a large number of dynamic options and display useful columns/links where applicable), we can obviate the need for the section link field. But it would probably be a good idea to keep it around, perhaps as an extension, to alleviate compatibility issues since some of you naughty people are using S2 in production environments. :P

... since some of you naughty people are using S2 in production environments.

Scott, we would never ever do something like this ;)

when filtering select boxes, it seems like you can only filter by exact strings and not the url parameter.

for example, let's say i have a url parameter of first-var that is going to be filtering a select box that has three values: First Value, Second Value, and Third Value. when i go to filter with {$first-var} in my Filter Results of my DS, nothing is returned. But when i filter by one of the three values in an exact string like First Value, anything that has been tagged with First Value will be filtered.

So it seems like the url param can't filter select boxes with the url value like first-value.

Is this the case or am i missing something on how to filter results?

Try using {$first-var}. Unless it was a typo in your post, your are missing the $ character to signify that your are filtering by a parameter.

oops. yes bauhouse, it was typo. thanks for the catch. i have corrected this error.

but that is what i have been doing all along: {$first-var}. i only get the error node when i try filtering by that.

It could be a bug, fields should be able to filter by either the actual string or its handle.

With regard to the "select box" operation one problem I've hit is when it is populated from another section (ie the dynamic options mode) and the field that it is referring to has values is not guaranteed to be unique. The example below probably explains the problem better better than I can:

Say I have a section called "song details" that has fields "artist", "title" and "label". Each entry in this sections details a song that has every be played on a radio show. I also have a section called "playlist entries" that holds the details about what tracks were played on what show and in what order. In essence it has fields "show", "order number" and "track".

Given the above the best approach seems to be to use a "select box" for the "track" field above and have the dynamic options populated from the "song details" "title" field. Using the data source chaining you can then produce the xml for a playlist and include only xml data for songs that were played. This works brilliantly until...

Say there happen to be two tracks with the same name. Using the select box there is no way to distinguish between the two tracks (it just displays the distinct values). In the case above the pkey for the songs is all three fields and none of the others are guaranteed to be unique.

To be honest, I'm not really sure of the way to solve the above. I just thought I'd mention it in case there was some way to accomplish it with the refactor that your doing. The approach that I was thinking of adopting was to create a read-only custom field that just displays the generated entry ID. In this way I would add it to the "song details" section and have the "track" select box field refer to it. It does then present a bit of a usability problem as you'll just see a drop-down list of IDs but at least it would provide a mechanism to link the two sections properly. (The section-link, whilst solving that issue, has the problem that a song couldn't appear in multiple playlists).

Anyway, perhaps it might be something to consider or else if there is a brilliant way to achieve this with Symphony as is please tell :)

Thanks Simon

Simon, there is no way around this problem in Symphony currently. But it is an edge case I've only been dimly aware of, so thanks for bringing it to my attention. With the planned select box field improvements, there will be links to each selected item, so following those links would help you distinguish options with the same name, but I'll think about this and see if we can come up with anything better. Maybe something along the lines of a mini-overview of the target entry perhaps?

allen wrote:

The current build of Symphony can already handle this with DS param output. What you want to do is create a data >source that filters by milestone and/or task (strings) and choose ID as the param output option.

So now, instead of grabbing from the URL Param $task, you grab it from the data source you just made: $ds-task.

sorry for bumping this topic, but i've been trying for the past 10 hours or so to wrap my head round this. :/

i have

• a page "/projects" with a url parameter 'handle'
• currently a datasource "projects" which filters SystemID by $handle

meaning that this works:

http://hostname/projects/project-id/

however, i'd like http://hostname/projects/project/ to work.

so trying what allen wrote above, i created:

• a datasource "projects_id2handle" with SystemID as the parameter output.
• and am now filtering the "projects" datasource with $ds-projects_id2handle

at the moment i've set "projectsid2handle" to only return 1 result, but i'm getting 0 results out of my projects datasource. that's the first problem. the second problem is that i have no clue how to get "projectsid2handle" to use $handle as an filter.

can somebody explain where i'm going wrong? i'm probably just being dense and missing the obvious, but i'm thoroughly stumped right now.

thanks, regards, sb

wait.... if you want http://hostname/projects/project/ to work, you can just just filter the Projects DS not by SystemID = $handle, but by Title (or whatever)= $handle... no?