New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the ability to allow for other templating engines to be used #2302

Open
bzerangue opened this Issue Dec 31, 2014 · 30 comments

Comments

Projects
None yet
9 participants
@bzerangue
Copy link

bzerangue commented Dec 31, 2014

In future releases, could the CORE be built to allow other templating engines (via extension) with the default still being XSLT? I am thinking, for the test case, the one template language to test this functionality, due to popularity and growth, would be PHP Twig. And then other users can bring in other languages like Lex, Razor… etc. (and use the PHP Twig template extension as a blueprint to how to build the extension). I think this would breathe new life back in to Symphony (meaning bringing NEW users to Symphony). The main barrier for new users considering Symphony is XSLT. Unfortunately, the web world seems to be running to other data sources (like JSON) and other templating languages (like Twig or Liquid) and leaving XML and XSLT to die a slow death.

Right now, Symphony’s tag line is “XSLT-powered open source content management system.” I think this is sending new users to turn the other way (with asking… what is XSLT or why are they using XSLT… must be old). Also, my guess it that this is also one of the reasons for the decline in our user base (especially main players like Nick Dunn, Craig Zheng, Hanna and Nils, Stephen Bau, etc.)

What if the focus was not on XSLT but on the flexibility of Symphony… maybe… changing the tag line to “API-powered open source content management system.” Bring your own templating system.

Symphony is one of the best content management systems out there. It seems as if Craft CMS took a peek at what Symphony was doing and built something you could customize to your liking (like Symphony) and using current web technologies and a current, well and actively supported templating system.

I am overly encouraged by the latest releases of Symphony, especially 2.5.x. It is by far the MOST stable releases Symphony has ever released. @brendo and company have done a marvelous job about listening to the community and implementing new/current technologies… JSON (via Remote Datasource) and looking at adding Composer to setup Symphony.

I thought I would ask to see if this could be considered for the future of Symphony and could be put on the roadmap, to add something that could make this system more relevant with current templating systems and to bring more users back to Symphony.

@bzerangue

This comment has been minimized.

Copy link
Author

bzerangue commented Dec 31, 2014

NOTE: There is a small little PHP flat-file CMS that is utilizing the "bring your own template system" via extensions. http://philecms.com

Just shared that because of the approach even though it is nothing like Symphony, I just thought it would be helpful to see how they were implementing this.

@nilshoerrmann

This comment has been minimized.

Copy link
Member

nilshoerrmann commented Dec 31, 2014

Right now, Symphony’s tag line is “XSLT-powered open source content management system.” I think this is sending new users to turn the other way (with asking… what is XSLT or why are they using XSLT… must be old). Also, my guess it that this is also one of the reasons for the decline in our user base (especially main players like Nick Dunn, Craig Zheng, Hanna and Nils, Stephen Bau, etc.)

I don't think this is true. At least for us, XSLT has never been a reason not to use Symphony for a project. If you are thinking of modern app and site development in an API driven world, the main problems lie in Symphony's half-baked event and data source implementations. Why isn't there an API at the heart of the system today*, that provides the data in different flavours (XML, JSON, CSV) that powers frontend and backend? Although this question might lead to different templating options, the main issue is data management: Symphony's concepts of data handling need to be revised (how to input and output data) and before this hasn't been done, discussing templating layers is pointless in my eyes.


* I know why it isn't there (man power, money, time) so this isn't meant to be reproachful. And I think most core developers agree that Symphony has missed a few important trends over the last years.

@jensscherbl

This comment has been minimized.

Copy link
Member

jensscherbl commented Dec 31, 2014

In future releases, could the CORE be built to allow other templating engines

It's the right thing to do. There's no good reason why this shouldn't be more modular.

I know why it isn't there (man power, money, time)

Exactly.

Why isn't there an API at the heart of the system today*, that provides the data in different flavours (XML, JSON, CSV) that powers frontend and backend?

[...]

Symphony's concepts of data handling need to be revised (how to input and output data) and before this hasn't been done, discussing templating layers is pointless in my eyes.

You're mixing things up here.

Frontend and backend are two separate things with different requirements. A low level API at the core that can be used by the backend, native apps (as backend replacement) and frontend data sources would be nice, but that has to be implemented on a lower level and has nothing to do with frontend templating, so we can indeed discuss these things separately.

From a PHP developer perspective, your flavors (XML, JSON, CSV) are output formats just like HTML.

Our data exists in PHP and can be transformed into any of these formats either directly with plain PHP or by one of the mentioned PHP templating engines.

XSLT is actually another layer sitting on top of that.

So what we need to do is this...

  • Pages shouldn't create output on their own and instead provide their data to a templating engine.
  • Templating engine generates and returns output back to the page.
  • Developers can choose output format (for content-type headers), templating engine and template per page.
  • Common formats are provided by the core, developers can input custom formats manually (input field with suggestions).
  • Default templating engine is plain PHP, additional templating engines are provided by extensions.
  • XSLT as a templating engine would act like other templating engines, data conversion to XML would be handled internally by the extension.
  • XML, JSON, CSV, etc. could be created by any templating engine, from plain PHP to XSLT. Most simple case would be a plain PHP template that just converts the data to XML, JSON or CSV automatically.
@jonmifsud

This comment has been minimized.

Copy link
Member

jonmifsud commented Dec 31, 2014

@jensscherbl I would some what disagree with the structure you proposed, however I do agree that it would be nice for symphony to offer separate outputs.

Pages shouldn't create output on their own and instead provide their data to a templating engine.

I would think that a page should be linked to an 'optional' template. Currently it's by default linked to the XSLT template + template engine which parses XML. Optional meaning no template would output the raw data be it XML or JSON. Besides Pages should not generate Data but rather set the output and process it (data is generated before it reaches the page)

XSLT as a templating engine would act like other templating engines, data conversion to XML would be handled internally by the extension.

This would need to be fleshed out more. All the current fields handle output to XML separately, this change would obviously mean that all Fields would not work anymore. I would think that the current XML Element would be morphed into an OutputElement, and that output Element would simply be extendible by extensions changing the datasource output from XML to JSON etc. Basically the generate function could by default output XML or PHP objects.

@michael-e

This comment has been minimized.

Copy link
Member

michael-e commented Dec 31, 2014

@jensscherbl

Frontend and backend are two separate things with different requirements. A low level API at the core that can be used by the backend, native apps (as backend replacement) and frontend data sources would be nice, but that has to be implemented on a lower level and has nothing to do with frontend templating

Nope. This is the old-school thinking of every CMS out there.

For Symphony the next step is not "add more templating layers, keeping the basic mistakes everybody makes". (That may be a nice idea for blogging platforms, which only need to get some comments from the frontend.)

If you want to build really cool stuff with Symphony (i.e. websites that can move towards being web apps, which is very important nowadays), it is really terrible that the frontend and the backend work completely different. If both worked the same way (regarding data, i.e. datasources/events/templating), it would be so much easier to build things. This is what @nilshoerrmann tried to explain.

@jensscherbl

This comment has been minimized.

Copy link
Member

jensscherbl commented Dec 31, 2014

I would some what disagree with the structure you proposed

With what exactly? What would be your alternative?

Optional meaning no template would output the raw data be it XML or JSON.

Raw data would be a php array or object in Symphony. XML or JSON needs to be generated by php. From a structural point of view, it's no different to HTML, so why would you convert to XML by default? Would also be necessary to convert back to php for other templating engines. Wouldn't make much sense in my opinion.

@jensscherbl

This comment has been minimized.

Copy link
Member

jensscherbl commented Dec 31, 2014

For Symphony the next step is not "add more templating layers

Valid opinion. But we need to keep discussions separate here in order to actually get stuff done.

it is really terrible that the frontend and the backend work completely different

Like I said, would be nice to have this, but it's another topic. If there's a low level API, you would be free to use it as you like, so the templating discussion doesn't take that away from you or restrict you in any way.

But for people to use Symphony as a CMS for building websites or their own custom APIs, there has to be routing, there have to be data sources, and there has to be templating. So what we're discussing here are two things. Should we leave everything as it is now, or should we make it more modular? And if so, how to implement it?

@jensscherbl

This comment has been minimized.

Copy link
Member

jensscherbl commented Dec 31, 2014

All the current fields handle output to XML separately, this change would obviously mean that all Fields would not work anymore.

Wouldn't be a problem, this would be a breaking change anyway and introduced in a major version release.

I would think that the current XML Element would be morphed into an OutputElement, and that output Element would simply be extendible by extensions changing the datasource output from XML to JSON etc. Basically the generate function could by default output XML or PHP objects.

Why make things so complicated? Just return php data from data sources, put everything together in the page, pass the data to templating and get back the output string (be it XML, JSON, HTML or plaintext).

@bernardodiasc

This comment has been minimized.

Copy link
Member

bernardodiasc commented Jan 5, 2015

Hey guys, this is a very good feature request. I've hacked the frontend output of a project, where the XML data was converted to Json string and parsed with Twig. Worked...

My suggestion is:

  • Include the template option in the install setup (might be changed later in the config file).
  • Pages will behave as usual, the main difference will be on the filename creation or renaming (page.xsl, page.twig, page.jade, etc).
  • Store data in a PHP Object and convert to any other data-handling language at will (This is a very good example of different output formats http://symphonyextensions.com/extensions/rest_api/).
  • When rendering the page, use the template engine selected in the config with the data in the needed format.

I dont have knowledge about how to do this extensible, so the list above describes how can be if the core have more template engines by default. Would be best if works with both behaviors (core and extensions).

@bernardodiasc

This comment has been minimized.

Copy link
Member

bernardodiasc commented Jan 8, 2015

I've been researching on several template engines, using some variety of parsers available.

More like an unpretentious experiment, launched https://github.com/bernardodiasc/elements/ this monday. Along other things, this is mostly a proof of concept about similarities and differences of template engines (currently with only 2 engines, still missing ways to inject Data in other parsers using Node).

Just for the record if anyone is interested. This project elements started as a Symphony Ensemble (beta generation https://github.com/bernardodiasc/modules) with just XSLT elements with a given XML schema. Sharing here for you take a quick look at. In the end of the day, the template engine choice is much about personal taste, what really matters is the Data (and I'm not saying the data transport language!).

@jensscherbl

This comment has been minimized.

Copy link
Member

jensscherbl commented Jan 8, 2015

launched https://github.com/bernardodiasc/elements/ this monday

Looks interesting, but has nothing to do with Symphony's templating layer if I'm not mistaken?

@jensscherbl

This comment has been minimized.

Copy link
Member

jensscherbl commented Jan 8, 2015

  • Include the template option in the install setup (might be changed later in the config file).
  • Pages will behave as usual, the main difference will be on the filename creation or renaming (page.xsl, page.twig, page.jade, etc).
  • Store data in a PHP Object and convert to any other data-handling language at will (This is a very good example of different output formats http://symphonyextensions.com/extensions/rest_api/).
  • When rendering the page, use the template engine selected in the config with the data in the needed format.

What advantages would that have over my proposal in your opinion? From what I understood, I think mine can achieve the same, but is more flexible.

@bernardodiasc

This comment has been minimized.

Copy link
Member

bernardodiasc commented Jan 8, 2015

Looks interesting, but has nothing to do with Symphony's templating layer if I'm not mistaken?

No and yes. This is frontend stuff, you actualy can use together with Symphony in your workspace and take advance of the XSLT templates just by importing in your page. What I'm trying to show is how template engines works. The general aspect is aways the same. Despite we call XSLT a template language, it is the only one that is not a template language, but a transformation language. This is something well known for XSLT developres, but out there, nobody understands the difference.

[edit] That's why I'm comparing same input and output with different template engines. At the end of the day, the template language choice is the same as choose Sass or Less. (reading this may clear what i'm trying to achieve https://github.com/bernardodiasc/elements/blob/gh-pages/HOWTO.md#templates)

What advantages would that have over my proposal in your opinion? From what I understood, I think mine can achieve the same, but is more flexible.

I agree with everything you said Jens. Just summing up. :)

@jensscherbl

This comment has been minimized.

Copy link
Member

jensscherbl commented Jan 8, 2015

I agree with everything you said Jens. Just summing up. :)

Ah, ok. Thanks for clarifying... :)

@bzerangue

This comment has been minimized.

Copy link
Author

bzerangue commented Jan 19, 2015

@brendo - any thoughts?

@brendo

This comment has been minimized.

Copy link
Member

brendo commented Jan 19, 2015

The current structure of Symphony doesn't lead well to this change being implemented at this time.

@jensscherbl

This comment has been minimized.

Copy link
Member

jensscherbl commented Jan 19, 2015

The current structure [...] at this time

Correct. We would have to change pages, data sources and fields for this to happen.

@allen

This comment has been minimized.

Copy link
Contributor

allen commented Jan 19, 2015

This request has been brought up several times in the past. Craig at one point even started creating his own templating language based on the fundamentals of XSLT. The world is moving towards JSON, that much is clear.

I think offering different template language as an option is technically all very feasible. Whether or not it is warranted is a harder question to answer. I'm too partial towards XSLT to offer an objective opinion, but I can at least outline some of my thoughts to share:

To determine if opening up the template layer to other solutions is the right path forward, we have to look at the following:

  • User Adoption — I think this is the key argument for proponents that are for the motion to expand the system's template layer offerings. I agree it will likely increase user adoption as XSLT is not a popular or intuitive language.
  • Added Functionality — XSLT, despite its flaws, is very powerful and comprehensive. I'm not convinced there is a templating language currently out there that offer significant improvements to XSLT (I will elaborate on this point further below).
  • Resource Allocation — This is one of the main arguments for proponents against the motion to expand the system's template layer offerings. I agree it is a major hurdle and I believe there are other weaknesses of the system (many of which have been mentioned) that should take priority over this.
  • Platform Identity — Brian mentioned an important point that Symphony's identity is tightly coupled with XSLT. This was a conscious decision made by the core team. Much of Symphony's philosophies were inspired and modelled after XSLT and we felt calling it an XSLT-Powered CMS most accurately described the system and its development philosophies. However, as to whether or not this is an obsolete way of thinking is not for me to weigh in on. The system has changed vastly and have taken a life of its own beyond the original core team's efforts.

I want to describe a few things that made XSLT so important to Symphony:

Firstly, no templating language that I am aware of place data as highly as XSLT. With XSLT, everything starts with data structure. Much of Symphony's ideas come from this. There's an inherent reverence to data when the templating language itself is declarative that is rarely seen in other languages.

The two obvious examples are CSS and jQuery…both languages are not templating languages and their node selectors are quite limited compared to XSLT. In addition, jQuery has its own host of problems that come with conventional programming languages, but I digress.

Secondly, XSLT is not an imperative language. The disassociation between the underlying system structure and the presentation layer I believe helped force the team to develop in fundamentally different ways. The clear and almost draconian separation of data, presentation and logic is an important strength of Symphony. PHP Twig for example behaves uncomfortably close to a conventional imperative language that, on the one hand makes it feel familiar to programmers, but also introduces potential bugs that otherwise wouldn't exist in XSLT (i.e. mutable variables). If PHP Twig does become a popular choice among future Symphony users, the development focus may then skew towards a more PHP way of thinking. Whether of not this is good or bad, I don't really know; nor am I necessarily opposed to it, but I think it's worth highlighting.

Thirdly, as already mentioned, XSLT, beyond what most other languages claim are strictly template-based languages. XSLT has the broader concept of transformation that is, I believe, a superset of what templates are. It's this idea that makes XSLT fundamentally more powerful than other templating languages I've seen to date.

Lastly, there are so many nuggets of ideas that XSLT bring to Symphony that regardless of if the software moves away from XSLT, I think it's important to recognise its influence in the system.

I want to point out that I may seem like I'm trying to sell XSLT really hard to the group but that's not really the case here. We've discussed in the past if moving away from XSLT was a possible direction we could take and I was on board with the idea. I am not opposed to expanding Symphony to offer support for other templating languages. If there is one key takeout from all of this, I'd like it to be for us to recognise just how much of Symphony was founded by the guiding principles of XSLT.

@jensscherbl

This comment has been minimized.

Copy link
Member

jensscherbl commented Jan 19, 2015

@allen I think the question is not if we should stick with XSLT or not. Even if XSLT remains the preferred choice for templating, there's no good reason why it has to be so tightly integrated everywhere and shouldn't be more modular, from an architectural point of view.

@allen

This comment has been minimized.

Copy link
Contributor

allen commented Jan 19, 2015

@jensscherbl yes, certainly.

I'm more focused on the fundamental question of whether or not it's a worthwhile endeavour to offer other templating languages as an option.

From what I can see the key motivation to offer other templating solutions is to increase user adoption. Are there any other important reasons that I have missed?

@jensscherbl

This comment has been minimized.

Copy link
Member

jensscherbl commented Jan 19, 2015

I'm more focused on the more basic question of whether or not it's a worthwhile endeavour to offer other templating languages as an option.

I don't think Symphony itself should offer other templating options. Only provide naked (php) data from the core, have XSLT as a first party extension.

From what I can see the key motivation to offer other templating solutions is to greater user adoption.

I don't really care about user adoption. I care about what I want to use as a developer.

Are there any other important reasons that I have missed?

More flexibility (as a developer).

@allen

This comment has been minimized.

Copy link
Contributor

allen commented Jan 19, 2015

I don't think Symphony itself should offer other templating options. Only provide naked (php) data from the core, have XSLT as a first party extension.

Yes, I wasn't implying anything else.

I don't really care about user adoption. I care about what I want to use as a developer.

Out of curiosity, what would be your preferred templating language?

@bernardodiasc

This comment has been minimized.

Copy link
Member

bernardodiasc commented Jan 19, 2015

Thirdly, as already mentioned, XSLT, beyond what most other languages claim are strictly template-based languages. XSLT has the broader concept of transformation that is, I believe, a superset of what templates are. It's this idea that makes XSLT fundamentally more powerful than other templating languages I've seen to date.

This is very true. I've researched several templating engines latest months (mainly to expand my comprehension on this subject). There is no one that do the job so well like XSLT. As @allen said, XSLT is a transformation language, which I think, not sure, it's the only one. All others are just "preprocessors" of HTML.

From what I can see the key motivation to offer other templating solutions is to increase user adoption.

Talking with a lot developers, I really can't convince a single one to try XSLT. I heard "XML is dead", "XSLT is old", "JSON is the right way"... well, opinions rarely substantiated, I know ([edited] these arguments are propelled by the javascript trend)... So, from my perspective, open doors to new developers is a strong point. They may start with JSON and while enjoying the fun building with Symphony start to know better XSLT.

While I stick to everything that XSLT provided to the system in a conceptual matter, it would be incredible to detach the template layer from the cms. This is pretty much the only non-flexible part of Symphony, I guess.

I care about what I want to use as a developer.

And this is important (choose your weapons!)! I aways choose Symphony to do my freelance work. But when in a company, it's pretty much impossible. Every attempt I have experienced failed when mention XSLT... you know, when you trying to talk and people already turn back to you... damn... :D

@bernardodiasc

This comment has been minimized.

Copy link
Member

bernardodiasc commented Jan 19, 2015

There is plenty attempts to make a XSLT way to parse JSON, didn't tried none yet. This is probably result of this dilemma: "why moving forward if something best don't even exists?"

Just as a reference about this: http://stackoverflow.com/questions/1618038/xslt-equivalent-for-json

@jensscherbl

This comment has been minimized.

Copy link
Member

jensscherbl commented Jan 19, 2015

Out of curiosity, what would be your preferred templating language?

I think I would either go with XSLT or plain PHP, depending on the usecase. With what I want to use as a developer I didn't mean that I don't want to use XSLT. What I meant was that I want to use (and develop for) a CMS where the architecture seems well designed and (hierarchically) logical to me.

While I stick to everything that XSLT provided to the system in a conceptual matter, it would be incredible to detach the template layer from the cms.

Agreed.

@bauhouse

This comment has been minimized.

Copy link
Member

bauhouse commented Jan 19, 2015

I worked with Symphony because it gave me the ability to do front-end development work that encouraged a true separation of data and presentation. XSLT forced me to think about building data models and creating HTML structures to present that data. But it also didn't limit me to the output of that data as HTML. I agree that transformation of data is the strength of XSLT.

I wouldn't mind if Symphony were to provide the ability to use different templating engines, but if the popularity of other templating engines starts to change the workflow that Symphony offers into something that no longer resembles the ideals that formed the foundation of what Allen, Alistair and Scott created, then I would question the benefit.

If the motivation is adoption, then the focus should be on why XSLT matters and less on popularity of the platform. If Symphony loses the distinction of being an XSLT-based CMS, it ceases to be much different from many of the other successful options available.

If I think back in history to the issues around adoption, XSLT may be one issue, but there are many others. I say this as someone who used to work for an agency where I was able to convince people to use Symphony for their intranet and for the public-facing agency site.

The adoption of Symphony as a platform was met with widespread resistance. I wasn't able to sell the idea very well, and people didn't buy in. There was far more going on within that agency that brought about the eventual replacement of Symphony with Drupal for the public-facing site and with Google Docs, Harvest, and Dropbox for the intranet.

As a member of the faculty of a local university, I tried to teach a class of design students how to use Symphony to build a site for an Interactive Design class. They clearly weren't ready for it and I have had to rethink this strategy to spread the word.

I've been working with other systems such as WordPress and Shopify for the past year to find out what benefits these popular systems offer. What I find is that clients care little about the inner workings of the systems and more about what you can do to make their lives easier.

The benefits that come with systems such as Shopify and WordPress are directly related to the speed and reliability of updates to the system, the availability of a wide range of well-supported and updated front-end designs or themes, and the extensibility of the system through well-supported plug-ins and third-party extensions that easily enable e-commerce and social media integrations and the collection of data to enable analysis of site metrics. Documentation and community-contributed tutorials are also key to the ability to develop and maintain these systems.

Without a community and ecosystem that is able to offer similar benefits, the idea of encouraging the adoption of Symphony CMS by changing the templating engine misses the core issues that stand in the way of widespread adoption.

If we want to spread the word about Symphony, we first need to prove that it warrants the attention. Then, we could learn a little about how to spread good ideas from Alex Pentland at MIT, whose research at the Human Dynamics Lab might shed some light on how to create healthy social networks through the concepts that they are learning about Social Physics. These are the ideas that they used to win the DARPA Network Challenge.

The WordPress ecosystem is quickly becoming what Peatland calls, in terms of social physics, an echo chamber. Symphony has the potential to spread what to many is a new idea about how to capitalize on the new world of big data and solve the issue of content management systems that Karen McGrane has been discussing for the last few years: separating content from form.

(continued in next comment because it was automatically truncated)

@bauhouse

This comment has been minimized.

Copy link
Member

bauhouse commented Jan 19, 2015

Perhaps the breakthrough will have to come from a separation between form and the systems that are used to manage the data contained by that form. For Symphony, it may mean that data consumption must be extended to eliminate the issue of the JSON / XML divide. If it can do both well, this will make it a suitable choice for almost any data transformations. The real benefit comes when designs can be agnostic of the system or platform that uses it. XSLT has the potential to solve this problem across multiple system architectures. The solution comes not from being part of an isolated subculture but from extending the reach of our little community and this idea across many siloed development communities.

@bernardodiasc

This comment has been minimized.

Copy link
Member

bernardodiasc commented Jan 20, 2015

Nice to know your experiences @bauhouse, good points you made.

Seems that this subject is more conceptual than technical. Not sure how productive we can be only imagining the result of this path. Moving forward while keep the roots is something I believe, but this is not my decision for sure. ;)

So... What I'm about to show is not pretty, actually will make your eyes bleed! haha

In this commit have some changes to inject Twig right before the frontend output https://github.com/bernardodiasc/symphony-2/commit/b37ca526aa85e6c6473174603acdd2120f83ac7f

more precisely, here is the crazy hack https://github.com/bernardodiasc/symphony-2/blob/b37ca526aa85e6c6473174603acdd2120f83ac7f/symphony/lib/toolkit/class.frontendpage.php#L308-L323

If you want to try, https://github.com/bernardodiasc/symphony-2/tree/twig is an ensemble with a section called "News" with 2 sample entries, and a Data Source (also called "News") attached to Index page.

Important: this is a hack, a ugly one with no other intention than be a proof of concept. working only with index. please, dont take this too seriously.

@bauhouse

This comment has been minimized.

Copy link
Member

bauhouse commented Jan 22, 2015

@michael-e, remember when Symphony 3 was designed to render the admin with XSLT? Surely there is something that we can learn from the old Symphony 3 beta repository to refactor the Symphony UI to render the admin area with XSLT. Perhaps it would also be possible to then introduce the UI enhancements that were being experimented with in the Symphony 3 beta admin UI at that time.

@bernardodiasc

This comment has been minimized.

Copy link
Member

bernardodiasc commented Jan 22, 2015

oh Symphony 3, so beautiful! :D

I would like to know more about the experiences you had on that, if possible. :)

Paraphrasing @nilshoerrmann:

Although this question might lead to different templating options, the main issue is data management: Symphony's concepts of data handling need to be revised (how to input and output data) and before this hasn't been done, discussing templating layers is pointless in my eyes.

Before someone get me wrong, while talking about templates and templates, the goal here is kinda the opposite. If we can focus on the data, the choice of the template will be indiferent (thats what I want to prove in my last comment). XSLT Engine Extension would be maintained by the core team and others engines by anyone who wants something else. An example application of delivery-data-only http://sailsjs.org/, well, this is just a framework, not a CMS, but its cool, use the imagination.

I'm too entusiastic in this subject, mostly by my previous (and current) experience with Wordpress, Drupal, Joomla, etc. Symphony have the outstanding benefit of the completely (almost!) freed frontend, while all CMS I know out there fail in this. I mean, generating HTML using plugins and black magic, all under the hood, seriously? ;P

@jensscherbl jensscherbl changed the title Add the ability to allow for other templating engines to be used [FEATURE REQUEST] Add the ability to allow for other templating engines to be used Mar 21, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment