Symphony.

Is there a wiki to detail what Ensemble is? I noticed in the preferences you can create an Ensemble by packaging your site as a zip. But then I am noticing Ensemble's that Bauhouse is creating, and they look like campfire services.

Say I want to have a default installation, not using the Spectrum default theme, but one to my own taste's, is that something I can do with the Ensemble function?

Yes. Ensemble, as I understand it, is a way to make your install (including theme, configuration, and data) portable. It essentially creates a re-installable clone, i think. So you can 'create ensemble' from, say, your localhost, move it onto the production server, unzip it, connect it to a db, and your install will actually be identical (data, sections, fields, and all) to the original.

So you could, I believe, edit the default install to modify the theme to your liking, and then create an ensemble with that. And that would be your new default installation.

This has been my experience, but someone correct me if I'm wrong.

Ok, so what is it that Bauhouse is creating? Is he developing sample sites that we can have?

Hmm, this could be just what I need for an idea I have. Websites out of the box!

More or less... It seems like he's developing a series of proofs-of-concept that illustrate how you can use Symphony to build a whole array of web applications. But he can explain better than I.

I have to say that is really powerful.

Indeed. It blew my mind a few weeks ago when I first zipped one up and tried to use it on another server. I couldn't believe it even migrated the data.

Yeah that's impressive too.

I can think of tons of ways to use that.

Now, if we could just install multiple ensembles into one Symphony site...

On first thought, that seems to me to be beyond the scope of what ensembles do, maybe even contrary to the very concept of ensembles...

And when I try to imagine how it could be implemented practically, all I can think about is the maelstrom of conflicts that could ensue—in the db, in the workspace, in the backend, etc.

aschooner: Out of curiousity, do you have any insights as to how it could be implemented?

Fundamentally I think it makes sense; the ability to integrate multiple pre-packaged symphony apps into a single symphony site ad-hoc should be a goal, imho.

I agree, the data management would be a nightmare. The DB would have to be able to add the needed structure arbitrarily and track what db structure matches up with what ensemble. I've never messed with CS/extensions, so I'm not familiar with how that stuff works.

In the workspace, though, I have a few ideas. I'm working on a system right now that uses namespaces to avoid template conflicts. In my system, every app or module for an app is referenced by an xml element with it's own namespace.

E.G. <ashooner:navigation id='3'/>

where the ID is an entry with the configuration of that instance of the module. Alternatively, modules that don't need their own entry could just take their configuration through attributes or child elements:

<ashooner:navigation type='tree' level='1' recurse='2' />

Using namespaces prevents conflicts in individual xsl template names. Also, you could (though I haven't) create a schema to validate usage of any of these module reference elements. An added bonus is that the namespace URI works as a standard versioning method. Another reason for this approach is that it allows you to place a module into the content of a page. So if my page template has 3 generic 'content areas', and I want to put an image gallery into one of them, I don't need to create a new page template with the image gallery xsl, I can just drop in the image gallery module reference element.

I'm still in the very early stages of this whole thing, though. Right now I'm just working on implementing this idea for basic page templating.

Our top priority with ensembles is to make them updatable, mainly so that you don't have to keep reinstalling from scratch every time Bauhouse updates his latest contraption, but also because this ability might be useful elsewhere, say, updating a live site after a number of incremental changes to a locally installed clone.

Alistair devised an ingenious way of making this possible, by matching and synchronising the relevant logs of the two Symphony instances. It may turn out that this model allows for some interesting possibilities like independently installing/updating partial ensembles, as ashooner and Nils have suggested, simply by filtering which logs get synchronised. But there really are a lot of factors impacting on whether or not this is possible, so I should warn against getting your hopes up.

Cool! I can't help it. My hopes are up.

Symphony is getting awesomer by the day!

Perhaps I jumped the gun. Updatable workspaces is still the goal, but the way we're planning to get there has changed since I described it. So, trembling with the fear of having to revise my statement a third time, I shall attempt to briefly describe our new (and cunning) plan:

Something that's been on our minds for a while now is a database importer that can, over time, be generalised to work with any DB structure, which would let you, for example, import from a Wordpress DB. Rather than build this as an extension, if it were part of Symphony's installer, then you could use the same infrastructure for Symphony updates. Updating Symphony will work the same as updating from an ensemble archive (and the same way as installing, for that matter), just that I guess Symphony updates won't have anything for you to add to your /workspace directory. Each time you perform an update, you get a fresh copy of whatever version of Symphony was contained in the ensemble archive, which then imports your previous data. The installer should let you choose what data to pull from the ensemble archive, where it should go, and what should have precedence (your previous data, or the new data) in the case of a conflict.

The very important conceptual difference here is that you get a new instance of the ensemble, which is then responsible for importing your previous data, instead of, as we originally thought, the ensemble trying to merge itself with your existing version. In normal circumstances, you won't get any warnings or complex decisions to make, but this approach allows for much more drastic changes between updates, like changing field types (in which case you'll be able to map old values from, say, a text input field to the new field type, say, a textarea field). Most usefully, it will also allow for non-sequential updates to the Symphony core, so you needn't worry if you miss the 2.0.1 update, going straight to 2.0.2 will work just fine.

Of course, the details are still far from certain, and I need another "don't get your hopes up" disclaimer. Alistair would probably be much better at explaining the nitty-gritty than I, but hold off asking him the hard questions until he's done with the implementation.