Symphony.

Has anyone ever worked with mustache? I would think symphonians would find it easier to just use a symphony install?….

It’d be interesting to see Mustache in Symphony as an alternative to XSLT in certain situations…

@newnomad and @alilm - I’m curious, why would you want to add an alternative templating system for Symphony? What are you trying to accomplish that can’t be accomplished with XSLT (or the use of EXSLT)?

I guess it’s not that certain things can’t be done is XSLT, but sometimes for the sake of simplicity (and readability) a system like Mustache would be very welcome.

The only interesting application I could see would be in the context of a text formatter. Not in the templating layer as a replacement or alternative to XSLT.

I’ve worked with previous CMS-es which had a similar approach to templating. Either by using their own built-in template language or something like Smarty (or Moustache).

I for one like the XSLT-approach more because it’s a standardized W3 spec, XML-based, well documented and example-ized over the Internet. Although it’s a steep learning curve learning how to combine XSLT with XML and XPath, I think is more solid than a scripted template-language.

Also, let’s not forget that the XSLT-parser is a native system component written in some language like C. Therefore it’s much faster in compiling templates than any template engine written in a script language like PHP for instance. I think that’s also the reason why Symphony’s pages load that fast without caching.

In theory I don’t see it as a bad thing for Symphony to support multiple view layer languages. In theory, communism works; in theory.

It’s just very XSLT-centric now though. It would require abstracting data sources from their output format (currently just xml) and Pages/Views from their output transformation (currently xslt).

It would be impressive just from an abstraction standpoint, but l have to admin, like everyone else, I’m pretty happy with just xslt.

The use of XML and XSLT is one of Symphony’s most distinctive characteristics and one of the main reasons it’s as powerful as it is. I can’t imagine us even considering adding support for any sort of specialty syntax in the templating layer. Just doesn’t make sense.

Craig: agreed.

I can’t imagine us even considering adding support for any sort of specialty syntax in the templating layer.

Thanks!

I can’t imagine us even considering adding support for any sort of specialty syntax in the templating layer.

Agreed.

@newnomad You can use it on JavaScript.

I was just arguing to use symphony instead of mustache when buildign a mockup of an application…

@newnomad: Moustache rocks, especially with Yehuda Katz’s changes. We’re using it on the hopefully-released-tomorrow update to Decaf Sucks and it’s the business.

Playing devil’s advocate…

@czheng

The use of XML and XSLT is one of Symphony’s most distinctive characteristics and one of the main reasons it’s as powerful as it is

I’d say that the essential characteristic of Symphony is it’s data view layer. By that I mean its rendering of a view’s data into a standardized, semantic form ( currently XML) before applying output view logic to it (XSLT). If Symphony will ever be able to utilize non-relational databases or semantic datastores, or XSLT2, XQuery, Moustache, etc., then some ability to modularize the form of the data views and output view logic will be needed.

@rainerborene Using it in Javascript is just what I mean. Imagine if Symphony could manage clientside views just as it does serverside?

Well, we’re agreeing in principle. It is the data view layer, which is XML/XSLT.

But on the implementation side, I just don’t see how abstracting and modularizing those components benefits the system enough to justify the overhead it would entail. That’s all I’m saying. Sure, it might be cool. I just can’t imagine we’d actually ever want to do it.