Symphony.

I’ve been using WordPress to power my blog since 2006. After a few months I became frustrated with its lack of flexibility in defining different types of content. So, I set about developing my own CMS with the desired flexibility built in. It worked reasonably well but I was dissatisfied with the amount of coding needed to add a new type of content.

Then I stumbled upon Symphony. At first glance it appeared to be just what I was looking for. I converted my blog to run on Symphony and imported my database (but I haven’t gone public with it yet). But it was not a real good test case – since it is just a blog – so I then used it to create another site that more fully exercised Symphony’s strengths. I still think Symphony is the platform for me.

But, I did struggle with the learning process. I found the Section - Data Source - Page scheme a bit hard to comprehend. The first two seem to me to be misnamed. Working with them became a lot easier when I realized that a Section is actually the data source (content) and a Data Source is actually a data stream.

A Section defines the type of content that you want to gather and provides the form for entering that content. It also defines the tables for storing that content in the database. In fact, the database can be filled with content before a Data Source or Page is defined. I think of a Section as a Content Type.

A Data Source simply defines the data that is to flow from the database to one or more Pages. That is why I think of it as a Data Stream. It is the pipe through which data is passed from the database to the Pages.

That’s just my two cents worth.

I suppose you could also call a data source a ‘data view’. When I’m explaining Symphony, I just refer to them as queries on their respective Section (which I equate to tables).

Thanks for the feedback. We do appreciate it.

In 2.1, we’ve renamed Pages to Views, which we think is a far better term. We’ve also debated the switch from Sections to Content Types, but it’s a little bit less of a ‘sure thing’… and we want to be very careful about not changing just for change’s sake. So we’re not forcing that one just yet.

The Data Sources question depends on your perspective I suppose. From a system overview perspective, maybe Data Sources isn’t a perfect term. But from the context of a Page, the term Data Sources makes perfect sense: it’s a source of data for the page.

Anyway, as we move forward, we’re always looking to make Symphony’s UI more clear and straightforward, so suggestions are always welcome :)

Pages to Views

Nice!

We’ve also debated the switch from Sections to Content Types,

Just my 2 cents, I don’t like that. In HTTP terms, 2 clients requesting 2 content-types could logically be served the same Section data in 2 different forms. I don’t want to convert my ‘user’ (Symphony data) ‘Content Type’ to the application/json or text/xml (Internet Media Type) Content Type.

We’ve also debated the switch from Sections to Content Types

Not sure I like this one. Models make more sense to me and will for anyone with experience with the MVC paradigm. That said, it is perhaps confusing for those who haven’t come across MVC before. If you’re changing Pages to Views that would work nicely as well.

Yeah… this is why we didn’t make the change. In some senses it works, in others it does not.

Clearly it’s a matter of personal perspective. I had no problem with Pages, but you are changing it to Views. Some agree that Sections should be Content Types, but others disagree. ashooner said he thinks of a Data Source as a Data View, but also said that changing Pages to Views would be nice.

Perhaps you should rename them to Composition, Instrument and Performance and let everyone affix their own meanings. But you would probably get lots of suggestions on altering those terms too.

At this point I’m fine with any terminology.

@czheng I think that models is the best term in this case.

Yeah, it’s not just a matter of picking whatever term makes most sense to you and me. We have to think about broader questions of accessibility, for developers and non-developers alike. At the same time, we want to think about standards and conventions. There’s no use introducing arbitrary Symphony-specific terms if they’re not necessary.

Allen and I have been discussing this quite a bit over the past few months, and we think the best thing to do is make the conversation public and gather feedback from all of you. I’ll be posting a new thread soon…

You’re right.