Search

This idea is in response to another thread where Allen talked about Symphony + XSLT, but I thought this idea probably deserved its own thread. I started by stating my position on XSLT:

One of the main reasons I have been involved in this community as long as I have has been XSLT, because I believe standards are the way to avoid endless fragmentation and because I believe they work. It's also the workflow and the approach to modelling data and the control over markup structures that make Symphony so great.

Adaptive Content

I think what would make Symphony even better is the ability to demonstrate true portability of templates between scripting languages, frameworks and platforms. If that could be demonstrated with XSLT, we would have both an approach (Symphony) and a templating language (XSLT) that could be used universally to solve the problem of adaptive content. Consider Karen McGrane's talk about adaptive content and how she defines it:

And so, I think when I look at the future of adaptive content, what I see is this really interesting interplay between saying, what are the people in content strategy doing when they’re wrangling the content, as they’re going up to business owners and saying, “How do you structure your content?” or “Here’s the chunks of things you need to write.” How does that eventually impact the data model in the CMS? How do you sync up the way that business owners and content strategists think about the structure of the content with how the database architecture or the CMS developers would actually create that data model, or the content model? And then those semantic structures that get stored in fields and metadata in the CMS, what’s the interplay between that and the style sheets? How much information is stored semantically in fields? How much of it is stored semantically in HTML and markup? And I think these decisions, they’re not going to be easy. But I think if we want to be able to create a great experience for every device, for every platform, what we’re going to need is people who are thinking thoughtfully about how do you have the CSS talk to the CMS in really smart ways. How do you have individual platforms be able to go and query the content, query that API, query the content as a service, and then figure out how to take that content back, how to display it in a way that’s appropriate. So, to me, this is what adaptive content is.

XSLT as a Standard to Unite Communities

The greatest barrier to adoption is not that XSLT is hard. CSS is also hard, but it's worth it. And it took a lot of advocacy for people to understand that.

In the agency where I worked, Symphony made a lot of sense philosophically. But clients wanted to avoid vendor lock-in. Choosing Symphony was akin to vendor lock-in due to obscurity. If you leave the technology choice to clients, they are able to find lots of vendors who can support their WordPress, Drupal and Rails projects. Symphony developers are not as easy to find. As much as we love our small community for the quality of its members, I think we need to consider how to grow our community to avoid the lock-in problem.

What if we were to look at the migration of community members to different scripting languages as a benefit? We have fans of Symphony who are becoming proficient with other scripting languages. Does this not open the possibility of expanding our community to other platforms and frameworks if we are able to adapt the Symphony approach to other systems? Of course, this is not an easy thing to accomplish, based on the size of our small community. But the community is only as small as the platform or framework.

If we build the Symphony admin with XSLT, each platform and framework community may have a greater incentive to adopt the Symphony approach and we can grow the philosophy and approach of Symphony exponentially. XSLT has a far better chance of becoming universally adopted as a templating language than anything else because nothing else comes close to having that level of support across scripting languages. What other templating language can claim cross platform support? XSLT, as a W3C standard, is in an excellent position to be as ubiquitous as CSS. What it is missing is marketing.

Symphony as an Approach to Managing Adaptive Content

Karen McGrane is advocating for an approach that sounds a lot like Symphony:

And that’s because, really, if we’re going to have content management tools to support this, we have to make sure that they can capture the content in a clean, presentation-independent way. We’ve got to get all that formatting cruft out of our content. More important — this is a really complicated issue — we have to figure out what’s the right level of semantic markup or semantic encoding that we have. How much of it lives in the CMS? How much of it lives in the HTML? What are the right decisions that we make there in terms of how something looks and works and gets styled?

I’m not saying that this is going to be easy. I think it’s going to be freakishly hard. But if we do it right, it’s going to create a much better system for the future. We’re going to have much better ways to reuse our content more flexibly

People need to know that this CMS already exists. If people have options to use the Symphony approach on the stack they are already using and to be able to easily migrate their data from one stack to another, that would be very hard to argue against.

Just thinking out loud here (and I agree with everything you've posted bauhouse)...

Would the first step of this be standardising some kind of Symphony XML doctype? Basically an XML document standard that other systems could comply with, making things like utilities work across implementations. I'm just imagining different implementations (or CMSs, whatever) all generating the exact same XML document when given the same data structure and content.

By their nature, other CMSs may be able to generate XML data even if not originally intended which could match this same doctype specification.

Does this make sense? I haven't had much sleep recently so it may not, but it seems we could leverage the power and interoperability that XML gives us.

We started a schema approach with the extension meta file, and I have a few outlines dotted around for schemas for our configs etc. Schemas are definitely the way to go if we want to allow something like this. If everything we do can be validated against a schema, then other systems can build the same xml.

I really love this idea, and it's one I have jotted down to get done for the new admin on Laravel. It makes sense to just get the admin built in XML + XSLT right from the outset.

Also, I have tried contacting a couple of web celebs that are as obsessed with modular content as I am, yet no one ever gets back to me. I fear that it is because I am a little known developer like the rest of us. We should reach out to these people and shove the Symphony concept under their nose. I read it so many times where they talk about what we all need, and keep thinking, "Hey! That's Symphony right there! Open your eyes!".

The greatest barrier to adoption is not that XSLT is hard.

I don't agree. This is in fact the greatest barrier. For people like us, learning a new thing isn't that much of a problem. But many people aren't developers and have a hard time wrapping their head around something like XSLT, or simply don't want to invest that much time in learning a complex new templating language. So they stick with something much simpler or with what they already know from Wordpress and other systems ("just drop that small PHP snippet here in your HTML").

Don't get me wrong, I'm all in for using and promoting standards and I totally agree with you from a conceptual point of view. But if greater adoption really is a priority for our community, we need to tackle things a lot more pragmatic.

What if we were to look at the migration of community members to different scripting languages as a benefit?

If we want to grow our community and reach more people, the way to go isn't sticking with XSLT and basing Symphony on other languages on the server side. Most well-known systems (like Wordpress or Drupal) are written in PHP, so this clearly isn't Symphony's big downside for most people.

XSLT has a far better chance of becoming universally adopted as a templating language than anything else

XSLT is around for a long time and didn't really catch on as a universally adopted templating language (due to its relative complexity, I guess). Not everything that's better also wins. Sometimes shittier technologies and approaches make the race (like HTML5 vs XHTML2 ;). We simply have to realize and acknowledge this.

XSLT as a Standard to Unite Communities

What communities do you want to unite if we're the only one supporting that standard (and only in an outdated version because of libXSLT)?

If we want to stick with XSLT, I'm fine with it. But don't make the mistake to think the problem for lack of adoption lays somewhere else.

Allen has it right in my opinion:

That said, while the concepts of XML/XSLT is vitally important, the language itself isn't.

@jensscherbl I would agree that the hardest part in adoption of Symphony is initially XSLT. I've had a hard time getting to grips with it around 2 years ago when I first started; and I'm still learning up to now.

I do not believe that it should be a barrier; but in order for it to not be a barrier we should set best-practices and use them throughout.

Not long ago brendon posted a repo how they use a sections folder with XSL files for each section; with different modes. I thought this was a great move one which I adopted in my latest projects. And has improved my development time significantly, the code is more readable then ever and can be re-used on different projects.

By having a set of these utilities/functions and an easy guide on how to build and use XSLT would be important. I'm not against allowing other template languages in Symphony, I'm aware it will grow our community much quicker. But we need to outline our preferences as a community and why we prefer these preferences.

I would think it would be a sad day when there are more users of symphony which create templates with php or other template layers without sticking to the Symphony Concepts. Let us remember that in XSLT the language is restrictive and clearly separates your Data & Template layer. If you had to use php like say Wordpress it tends to become fuzzy.

@gunglien Again, I don't have a problem with XSLT.

But you simply can't talk about growing the community and at the same time reinforce the biggest thing that holds back adoption. We simply have to decide what's our priority: Wider adoption and a larger community, OR sticking with XSLT.

But... Maybe... If we are clever...

As mentioned before in other threads, we don't have to think only in black and white. If we open up a little bit and decouple Symphony (Core) from XSLT, providing XSLT templating as just another extension (maintained by the core team and updated along with new core releases), we could lure in more people, make them familiar with Symphony first, and make them aware of XSLT templating and its benefits afterwards.

Possible downside of having different approaches to templating is more fragmentation inside the community.

@jensscherbl don't get me wrong I would fully support Symphony trying to widen its userbase with support for php based template languages. Its a matter of how you would put it. I think an extension bundled by Core Devs would work well enough.

But... Maybe... If we are clever...

That's exactly the right phrase.

I think we should educate on how a template layer should be used, and obviously promote XSLT & other standards if that's what we'd still like to continue building upon. So users who start using Symphony because of Symphony are then getting exposed to XSLT & the like.

From my experience, XSLT is used a lot in other, highly data driven contexts. It seems to me that XSL has an adoption problem in the PHP community and – as a consequence – in the mainstream web development.

But I agree, the philosophy behind XSL is what matters. Still, I've not seen a template language beating XSL concept wise.

So users who start using Symphony because of Symphony are then getting exposed to XSLT & the like.

Exactly. But as long as XSLT is mandatory and not optional, those users might not try Symphony in the first place, or fail pretty quickly and move on to another system.

Ah, and one thing we shouldn't forget when we are talking about the templating layer and XSL: one of the most important features – especially when relying on the ninja technique – is xPath.

But I agree, the philosophy behind XSL is what matters. Still, I've not seen a template language beating XSL concept wise.

I think our main focus shouldn't be to find another templating language that imitates or beats XSLT, but to maintain the strict separation between Symphony's data output (currently the XML) and the frontend output that is generated by templates.

I think our main focus shouldn't be to find another templating language that imitates or beats XSLT, but to maintain the strict separation between Symphony's data output (currently the XML) and the frontend output that is generated by templates.

I fully agree. As long as there's a strict separation it would be quite easy for anyone to make the switch in between template languages.

Symphony is about the flexibility and the power of an approach to managing content that is unique because of the strict separation of data and presentation. I am not against making Symphony even more flexible by enabling the ability to use different methods to achieve the same thing.

Growing the community is an important factor in the longevity of this project. So, if XSLT is the greatest barrier, then we probably should make Symphony flexible enough to use multiple data inputs and multiple templating options for output. If we can do this while retaining the key differentiator, that XML and XSLT remains one of the core options, I am all in favour of this.

In fact, that's basically what I am saying by opening the idea of porting the Symphony approach to other frameworks. It's the approach that is important. People should have choices. It just seems as if XSLT has not been an approach that has been promoted as a viable option in other frameworks. It seems that XSLT has not been tried and found wanting, but rather it has been tried without being fully understood.

When I read about the reasons people hate XSLT, it is usually because they do not understand it. I don't necessarily want to force them to use it. I just think they should have the option to learn how to do it right, then make a fair assessment about whether it is the right tool for the job. Those who invest the time reap the benefits. XSLT may not be the right tool for every job, and that's fine.

So, I think you are right, Jens, that we may need to make Symphony even more flexible by increasing the options while using the same approach. If that's what we need to do to grow the community, then that's what we should do.

What about thinking of XSL as the professional templating layer that is also used to create the backend and other templating layers for first-time users / unexperienced users?

XSL as the professional templating layer that is also used to create the backend

If Symphony should be re-written, creating the backend with XSLT is a must-have.

What about thinking of XSL as the professional templating layer that is also used to create the backend and other templating layers for first-time users / unexperienced users?

Nothing wrong with that.

The discussion is titled How to grow the community, so let's move it away from XSLT for now and into another direction. This also concerns Stephen, as he's building the new Symphony site (I guess).

For me, an important part of a project like this is how well it is organized and communicated.

I still dislike the approach of outsourcing stuff like extensions, documentation and community to individual people and hosting them on different domains. This is important for the ecosystem and should stay part of the main site, which is owned and maintained under one roof (either Symphony as a project or maybe Soario as a company).

For example, Nick isn't involved in the community any longer or even using Symphony since he switched jobs, so who's taking care of the extension site now?

Let's take a look at ProcessWire instead. They do a pretty good job in that regard.

The project clearly communicates where it currently stands and where it's heading, short term and long term. Their documentation is very good, with code examples and text that's actually readable (not just API docs). And there are a lot of tutorials as well. Also, there's a well structured download area for extensions and other stuff.

But most important: All that can be found in one place, the main project site. Just like it used to be on getsymphony.com. Why making things so chaotic and complicated?

@Henry:

Would the first step of this be standardising some kind of Symphony XML doctype? Basically an XML document standard that other systems could comply with, making things like utilities work across implementations. I'm just imagining different implementations (or CMSs, whatever) all generating the exact same XML document when given the same data structure and content.

@designermonkey

We started a schema approach with the extension meta file, and I have a few outlines dotted around for schemas for our configs etc. Schemas are definitely the way to go if we want to allow something like this. If everything we do can be validated against a schema, then other systems can build the same xml.

Yes, I think this is a good place to start. The next version of Symphony has to think in terms of schemas. We don't have to reinvent the wheel here. But portability should be a driver in the decisions.

Let's tap into the wisdom of other communities to benefit from the cross-pollination of ideas. Google is leading by recommending the use of microdata:

Google suggests using microdata, but any of the three formats below are acceptable. You don't need any prior knowledge of these formats, just a basic knowledge of HTML.

I would think that Symphony has a lot to contribute to this discussion.

@jens; yes and no. Having separate sites might actually be good if they are built up properly.

I would fully agree that there should be a team which can take-on & work on some of the sites. Such as the example you brought with the Extensions Site, it was a marvellous piece of work back at the time; however the community might want to bring along other updates.

As regards the fragmentation; with the way Nils & Johanna have been doing I don't see much fragmentation. Separate sites might be good for the eco-system. At my primary work the biggest project we have been given was essentially that of Splitting up the Main company's website into separate satellite sites. We're still inter-linking using a common header however it allows you to somewhat vary the design and structure of each website making them adapt to their purposes.

Please have a look at this discussion regarding the domains: https://github.com/symphonycms/factory/issues/37

You have to differentiate between "installs" and "domains". So it's not that much about outsourcing but about allowing development at different speeds.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details