Symphony.

Scott mentioned the "intra-section-multipliers" concept a while back - this is something I'm very, very keen to see in Symphony (it's one of only a couple of items I'm really hanging out for if it is indeed what I think it is).

What are the chances of seeing this in Symphony 2.0? Will we have to wait 12 months until 3.0?

There are two models we had prototyped for S3 (not to be confused with the Amazon service), and we've settled on the latter:

1. Add a new field type (called "subsection") which is effectively a bunch of foreign keys linking to entries in other section. It would be very much like the reverse of a section link in S2, with the forms for linked entries displayed inside the parent entry's form, similar to how the field widget works on the section form.
2. Have a mechanism for grouping fields within a section ("fieldsets"). Add an option to each fieldset to the effect of "this fieldset can be duplicated". This makes it so that there are no longer orphaned entries in a subsection, and solves a lot of problems with DB design that the previous solution caused.

Retrofitting either design into S2 would be very difficult. The first solution would be easiest, but there'd be no good way to handle field errors: If there's an error in a single entry (parent or child), no entry should be saved, and to get S2 to work this way would require some very complex management code. We decided that the huge class of bugs this would introduce isn't worth the benefits over the current design.

The second solution would break backwards compatibility, so we don't plan to do this in S2. However, if there are any clever developers who can think of a third way (or any other design improvement to section links), we are definitely interested to hear about it and/or see it implemented. There could be some interesting field type extensions designed for this.

Scott, is the idea here that what were once discreet subsections are now just sets of fields within the parent section? Hopefully not, as that would be extremely restrictive.

Yes they are. I can't see what's restrictive about that. Can you explain?

Well, I can think of a ton of reasons why this seems counter-intuitive, but a simple example is this: You've got a section called Books and a section called Authors. You need to have a many-to-many relationship between them. A single author can have many books, and a single book can have multiple authors. If I understand correctly, in the replicable fieldset scenario described above, you could only have a single section, either Authors or Books, and the other would become only a set of fields within the parent. To me, it's clear why this would be a huge drawback. What if Books is my parent section, and I want more than just a name for each author? What if I want things like date and place of birth and death, a short bio, a photo? Do I have to re-type and re-enter those for every one of their books? And what if I wanted to be able to attach comments or notes to both Books and Authors? What if I want to be able to do both of the following: display all Books categorized "poetry" and display all Authors born in the 1920s?

One of Symphony's great strengths IMO is the ability to both flexibly and accurately model a domain or system of content and relationships and it seems to me that this solution takes a lot of that away... correct me if I'm wrong.

If you wanted a many-to-many relationship, you wouldn't use a subsection, you'd use a multi-selectable select box section link (or just a plain select box in S3). I don't think you could logically display all the entries of a many-to-many relation on a single page, or at least it would be very complicated if you could, and we don't want to attempt this in the core.

The point of subsections is this: You want to attach an arbitrary number of image entries to an article entry (or journal/issues, vendor/product, etc). Image entries on their own aren't useful and it's a hassle to create the entry first then go elsewhere to create each image. Since the process is two steps, if the article entries are immediately published, there's a brief period where they don't have all their images associated. Subsections just provide a streamlined interface for a subset of linkage use cases; we don't intend to make links impossible through other means.

Ah, never mind then ;) I was worried that the subsections thing was intended to replace more robust section linking...

I was thinking some time ago about an (extremely) fudged way of providing "inline sections" within S2. My thinking started with the Wordpress view when writing a Post. There is an iframe under the post which loads in a series of thumbnails which, when clicked, add the image path to the textarea in the parent page.

This exact functionality could be replicated using an iframe and some CS trickery. It's not elegant, but it would work. Taking the "Post and Photos" paradigm, in Symphony one would create a Posts section, an Images section, and the Image entry has a section link back to a Post. One could write a new field type called "Inline Section" to which you add to your Posts section. The field accepts configuration options of "Section" (a drop down of existing sections) and "Link Field" (the name of the section link in the Images section, in this instance it may be called "Post").

When viewing a Post, this "Inline Section" field would write an iframe onto the page. Th URL of the iframe would be in the form:

/symphony/publish/images/?filter=post:1234&inline=true

Where the string "images" is the handle of the Section from the drop down, and the string "post" is the handle of the "Link Field" value.

A slight modification to the page <head> would allow the writing of additional CSS rules when inline=true is in the URL; these rules would hide the header/footer and style appropriately.

As I say, not an elegant solution and is only suitable in a limited number of cases. However since at the database level section links work pretty much as one would expect, I see this as more of a UI challenge than an architectural one. And indeed one that could potentially be solved (or at least partially solved) by the use of Extensions, rather than modifying the core.

I did start to look into this myself, but couldn't get a custom field type to work. I may try again when some free time arises, if anybody thinks it's worth pursuing...?

Update: thinking about this further, the page loaded into the iframe could be a completely customised page altogether. It could be created through an extension as an additional Symphony backend page, or it could actually be produced in the front end as an XSLT Page, styled to look like Symphony. In my example above, it could potentially show image thumbnails and so on. It would require customising for each instance however. Going with the "hiding of certain parts using CSS" method would make this work on any linked section.

This is exactly what I would like to see available. 21Degrees guys - how difficult would it be to implement something similar to what Nick has proposed above?

how difficult would it be to implement something similar to what Nick has proposed above?

Fairly straight forward I would think, since it's just an iframe. One could create a custom field extension to add this functionality.

Along the lines of making it the product of a frontend xsl page, why not make it a full-blown media browser with categories, upload field, and even configurable dynamic datasources (e.g. flickr).