Symphony.

This suggestion is related to the following bug report

The seeds of an idea

In the bug report referenced above, I pointed out that in system author fields, Symphony was only grabbing users' first names. Thus, if you've got multiple authors with the same first name, these fields become almost unusable, as you simply see the same name repeated. My first reaction was to file a bug report asking that the full name, or firstname + lastname, be used. Then I thought, maybe they should be configurable, so developers can choose for themselves how authors are referenced internally...

The "Aha!" Moment

A few days after that, I realized that extending this idea of configurable internal referencing could actually solve another problem I've been trying to figure out...

I'm building a site that uses a section for non-user authors. As of right now, I'd have to give this section three separate name fields: first name, last name, and full name. first name and last name because I need to be able to do granular sorting, etc. full name because when I choose the author(s) of any given article, I need more than either the first name or last name to do it. But this sort of thing is only necessary for the backend, since I can use XSL on the frontend to construct whatever combinations or permutations of data that I want.

Again, my first reaction was to hop on IRC and ask Alistair whether it would be easy to create a sort of autocalc field type, one that could, say, concatenate two other fields. It didn't look promising...

The Suggestion

Now I'm thinking that maybe Symphony should have the built-in ability to configure how section entries (and some system objects) are referenced internally. When creating/editing a section, you might get one of those blue "configure" buttons. Clicking it reveals a text input called "Entry Handles" or some such—into which you can input a combination of static text and field references joined by the "+" operator or something. If you want to get fancy, you can provide clickable options (like how tag lists work) underneath the input which pulls from existing fields (excluding text areas, etc).

Why I Think It Might Be Good, pt1

For the system authors problem, this means that admins would have the option of choosing how authors appear in menus and such: "Allen Chang"; "Chang, Allen"; "Allen"; etc.

Why I Think It Might Be Good, pt2

In the scenario I've described above, I don't have to capture redundant data. I have two fields, first name and last name, and get to choose whether these entries are referenced internally (in system menus and such) with a combination of these two fields (e.g. first name + " " + last name), or in some other way entirely...

Why I Think It Might Be Good, pt3

In a third scenario, it would help me capture data in a more granular and meaningful way. For the same website I referenced above, I have a section of journal issues. Each issue's title is a combination of the volume and issue number (e.g. Volume 19, Number 3). But much of this text is superfluous. What's really important are the numbers. I need to isolate them. Right now I can either create redundant data (e.g. additional fields for each number), or use XSL on the front end to extract them as substrings (which is what I'm doing now). If I could configure how they were referenced internally, I wouldn't even need a title field. I'd just tell the system to reference them with something like "vol" + vol_number + " " + "no" + iss_number

A Small Question

If this were implemented, it's likely that I'd create another problem for myself: what do I use in URL params? If there were no full_name field, would I lose the ability to have URLs like authors/john-doe and issues/vol19no3? Or could the output of the configurable "handle" be used?

The Big Question

What do you all think? Would this be helpful/desirable? Is it even possible?

I think this is an excellent idea. I work with/maintain an academic-management database (Access), and this is precisely the functionality it has. We have "Surname" and "GivenName" fields, and can either use these discretely, or combine in an expression like FullName: [GivenName] & " " & [Surname] for use on a transcript or whatever. Very useful.

How one would do this with XSL and Symphony, ... someone will know! :)

David.

Naming entries has always been something we've struggled with, but I think you've actually come up with a useful and elegant solution. Well done!

Entries have some implicit "system" fields, like ID and created/modified dates; I see no trouble in adding another for this. It would just give data sources an extra field to filter/sort by, so it wouldn't interfere with current functionality.

In keeping with the XSL-style syntax, I'd add one extra input to the Sections form, which could be formatted like

Vol. {$volume-number}, No. {$issue-number}

as though entries was the context node.

Awesome. I love that the syntax would be consistent with everything else. Thanks, Scott.