Symphony.

Continuing the conversation:

@bauhouse:

I’m hoping that some effort will also be put into how best to aggregate sections from different Symphony ensembles. With the latest updates to the installer, I would imagine it would now be easier to create an extension that changes the SQL to add sections, fields and entries tables to an existing Symphony install.

This would be a killer feature and would certainly propel Symphony forward as an extremely extensible CMS. If no one else takes this on, I’m going to have to figure out how to do it. That, to me, is the way forward.

@nickdunn:

I’ve tried, and it’s near-impossible in its current form. But this is definitely worthy of a new thread sometime as I have some ideas to discuss.

@ashooner:

@nickdunn … The first step in modular ensembles is namespacing Sections. This way, not only can you avoid name clashes in the data model, but also in the xsl templates that would act on them. Since each section is associated with a URI, there is no collision. Namespaced Sections would also allow for inter-operable ensembles, so a ‘members’ ensemble would have a recognizable namespace:field that other apps/ensembles can link to through link fields, etc.

A way to export Datasources. This is the trickiest, since it would require modeling the state (ie the param pool + page url params) in order to accommodate using them in the DS queries

Last, a way to define a Page class or template which would use the datasources.

Of course all this would need an import/export extension, which would be no small feat. Looking into extending a Section (in order to add namespace URIs) I see that the Section ‘Create’ delegate is broken.

It’s not only technically tricky. Let’s say you were building a site with a forum, members, and a blog. That’s only three main functions. Now, if you were doing this from scratch, think about all the decision points you’d hit in that process. About how things should be structured. How relationships work between different types of content. How do you automate that?

When maintaining development, staging and production versions of database I’ve found it really difficult to migrate changes. If I modify a section (adding a field) on dev, I’d have to repeat the same on staging and production. If I add multiple fields, I need to make sure I do these in the same order, so that internal section and field IDs remain consistent between builds.

The reason for this is that field and section IDs are stored in Event and Data Source PHP files. If I create and delete a field on dev, then add a new one, there will be a gap one of in the consecutive IDs. If I don’t do the same on staging/production, creating a new field manually on these databases means the IDs are out of sync.

I’ve created an SQL query logging script. It requires a small core modification, but it logs every single SQL query made by Symphony into a log file. At the point of logging the query I parse the string for table names and make sure I only log structural changes, rather than content changes. This means I can make a load of changes to a development server (adding pages, sections, fields), package these into an SQL dump and run them on other builds, bringing them up to date. The key is that the content is not modified, only the structure.

I think the same principles could be applied to ensembles. So long as sections, fields and pages are named uniquely, then we can export them as SQL files.

The problem is that Data Sources and Events also house the ID values of fields and sections. The core would need to be modified so that it stores the handles of these instead, but this introduces the problem of what happens when names are updated.

To be able to accurately export a Section/Field combination and ensure its Events/Data Sources remain in sync, at the point of import into a new project the IDs in the PHP files would need to be updated with the new IDs generated when importing the SQL.

Tricky, huh.

Incidentally the development of my query logging tool above was the rationale for thinking about Storing Pages as PHP files rather than database entries. Since an Extension can already bundle Fields, Data Sources and Events, I figured that adding Pages to this mix (and perhaps Sections too) would blur the lines between Extensions and Ensembles, perhaps even making the latter redundant.

Then, activate the feature set by enabling an extension. Need a blog? Install the Blog extension. Need a forum? Install the Forum extension. Need a calendar? Install the Calendar extension. I like the idea.

But then bundling an entire project management solution into an extension seems like the wrong fit.

It’s the PHP part of things that I have reservations about. Extensions tend to exclude the XSLT developer and this doesn’t seem to me to be the Symphony way. And if the dev team are moving toward an XSLT-driven backend for Symphony 3.0, I’d like to know how much extensions development will also be moving in that direction.

And if the dev team are moving toward an XSLT-driven backend for Symphony 3.0

To me this is one of the most interesting ideas for Symphony 3.0. Any technical or conceptual distinction between backend and frontend might disappear.

More than anything, that’s what I was hoping to demonstrate with the ensembles. Why shouldn’t the admin area work the same as the front end? XSLT should drive the whole thing. I think it might have convinced the dev team that it was worth the effort to go the XSLT route.

This opens the door for core and extension development to a hybrid group of both front end XSLT developers and backend PHP developers. Knowing that it’s coming, I want to make sure that we have some good front end work already built to make use of the new XSLT-based admin.

@bauhouse

I’m definitely in the ‘more xsl’ camp (sometimes to a fault I think). I’m cooking up an extension soon for what I’m calling ‘output events’ which are basically events triggered by particularly namespaced output from the transformation. This could be PDF output, an email, write to a data resource, or any REST action. Ive considered hijacking the transform itself to allow for php functions.

@nick

I’m thinking in the opposite direction, to make it a higher-level function. You’re clearly more familiar with the API than I am, but why not determine the best way to describe the different components (sections, DSs, Pages, events) abstractly, and let a utility extension translate that into API commands. Sure there would be a necessary sequence (Sections, DSs, Events, Pages). Does the API require you to write your own SQL to add any of these?