Things it should have

[nils-werner]

Just a list of things I think Next (and the framework it is based on) should have. Feel free to append anything you think is important

• PSR-0 compliance
• composer.phar package
• ORM
• Ability to swap out the templating layer
• Builtin DB migrations
• Command Line Tool
• PHPunit/TravisCI integration

Granted, those are all features I've seen in Laravel. I am just blown away by the possibilities they offer.

[bernardodiasc]

Thanks @jensscherbl. The discussions about language and version closes the case. Is there any conclusion about status or core ACL?

[jensscherbl]

There are two extensions covering that.

• Versioning
• Author Roles

I guess the authors of these extensions could provide some insights about past discussions on these topics.

[jonmifsud]

As far as I'm aware the current versioning extension in symphony; uses files to keep track of entries; saying this as on our multi-server setup when it was setup we had issues with versions being in-consistent across the machines. (basically rendering it more or less useless...)

On 18 May 2013 18:01, Jens Scherbl notifications@github.com wrote:

There are two extensions covering that.

• Versioning http://symphonyextensions.com/extensions/versioning/
• Author Roles http://symphonyextensions.com/extensions/author_roles/

I guess the authors of these extensions could provide some insights about past discussions on these topics.

— Reply to this email directly or view it on GitHubhttps://github.com/symphonycms/symphony-next/issues/1#issuecomment-18103483 .

[iwyg]

Please don't use versioning. Really. Don't.

Besides of that, versioning and author roles are completely different things as I've pointed out here. There's a reason why I've never released the current version of versioning and that's because of the ACL extension. Why? because it was a mess. Versioning is quite useless without a granular control over draft/staging/approval operations which the current user model of symphony is not capable of. I wrote the versioning extension with the powerful entry staging system of typo3 in mind. The ACL extension did basically what I needed but as I already mentioned, it was a mess.

First conclusion: Entry versioning is dead simple, hooking into the (locked) usersystem is not. IMO what we really need for __next* is an extendable ACL. Things like version control could easily be handled through extensions (depending on the entry model system).

Second conclusion: if I need a complex draft/staging/approval system, I don't use symphony. Third and last conclusion: no offence but dont't use Author Roles either. Really, don't.

[ijy]

@iwyg That's all really useful to know, for the current implementation and for future considerations to Next. We don't want to be repeating past mistakes so an extendable ACL sounds like a must in allowing some of the above suggested features.

[brendo]

Check this out, Fuel has implemented a abstract template layer. Available options are Markdown, Mustache, Twig, Smarty and raw PHP. Simple concept!

[iwyg]

Yes, you can do this in most of the frameworks, although they might not come with this out of the box. I think the biggest problem here is that xstl works completely different compared to other (native) templating layers. Most things these solutions are capable of in leveraging some framework awesomeness, you can't do with xslt. E.g. with Symfony/Twig you'd be able to make sub-requests from within the template, which is super handy when your site hast both, static and dynamic parts, or, as another example, bind a form directly to your data model.

That doesn't necessarily mean xslt cannot live side by side other templating layers (see xsltbridge), But you have to be aware that you cannot simply drop-replace it with another one.

[nickdunn]

I second @iwyg, that XSLT is more than a templating language in the traditional MVC sense. Strictly, templating should be logic-less. The power of XSLT is really in XPath and the ability to cross-reference data. Because Symphony's requires you to chain data sources, you need XPath to pull the data together and pluck values from different parts of the XML.

Symphony's object output would mean separate data sources for each model (a customer, a list of orders, a list of products for orders). XPath is needed to cross-reference by IDs to render these. However if in the XML a "customer" object has a child object "orders" which has child objects "products" then you don't need complex XPath and can use a simpler templating syntax to bind the objects to your rendering.

I think you can only introduce a simpler templating/binding syntax if Symphony does more to provide you with the data in a more structured format, removing the need for the view layer to do this restructuring itself.