Symphony.

Compared to our Symphony forum it's rather chaotic and very ugly.

Agreed, but they aren't designers over there.

Even Symphony (the system that should drop all its code, people say) runs a forum based on Symphony!

Not the first 4 or 5 years ;)

:-)

I just wanted to say "it's not all gold, maybe".

Michael, my understanding is that we could abstract the Core Email API work and use it as a bundle in Laravel, so we wouldn't have to use Swiftmailer.

To clear up the templating conversation I seem to have sparked. Symphony will always use XML/XSLT by default for the reasons people have already said. I think it would be beneficial to investigate templating as a pluggable layer so that if someone wanted to use something else, they could. David's suggestion is pretty close to how I saw something like this working and when you think about it, we already do this, it's just extensions never get a chance to change it to something else. For what it's worth, Craig had conceived a similar idea some time ago and it looked quite promising!

I agree with Simone, Symphony to me is the philosophy of reusable content and never assuming anything on the frontend. XML/XSLT is a bonus, something that I love and won't stop using, but I think we could share the additional benefits of Symphony, with a greater community if this barrier was removed.

Time for my annual post.

It should be possible for the software to maintain multiple independent instances of itself inside of the one PHP instance.

At the moment there are at least two awful hacks commonly used in Symphony:

• Fetching pages over HTTP from one Symphony instance to use as an email body, or similar. This means that some requests to Symphony can tie up two or more HTTP requests on your web server that should be handling visitor requests instead.
• The Debug/Profiler DevKits work by injecting themselves into place, while it works it does not make a lot of sense from a program flow perspective and can make things difficult to debug.

In both of these cases we'd be better served if it was possible to simply spawn another independent instance of Symphony to do the processing. Instead of creating a HTTP request to fetch and render an email body, you would use this pseudo code:

$email = new Email();

$s = Symphony::create('/path-to-email/page');
$email->body = $s->render();
$s->close();

$email->send();

The debug use case is a little more complicated, you're already in Symphony, and now you want to replace what Symphony was going to do with something else:

$s = Symphony::current();
$clone = $s->clone();

// Run the clone as normal:
$html = $clone->render();
$doc = $clone->document();
$clone->close();

// Render the debug view and done...

As far as I know none of the frameworks really support this kind of pattern.

As far as I know none of the frameworks really support this kind of pattern.

Multiple instances of the whole application? Your pattern is wrong!

• If you want to send an e-mail and you must clone the entire application, then something goes wrong.
• If you want to debug your application and you must run the app a second time, then something goes wrong.

Same framework, but different application. The "email" would be an application and the "debug" would be an application.

• If you want to send an e-mail and you must clone the entire application, then something goes wrong.
• If you want to debug your application and you must run the app a second time, then something goes wrong.

Agreed. Sending e-mail inline is painful anyway. It's slow an it breaks stuff.

The "email" would be an application and the "debug" would be an application.

Why?

Pseudo code for one application:

$service = new Service();

$view = new View();
$view->assign('content', $service->get('someContent'));        

$email = new Email();
$email->setBody($view->render('view-scripts/email'));    

$view = new View();
$view->assign('content', $service->get('otherContent'));

$htmlResponse = $view->render('view-scripts/html');

For those who are interested: Symfony2 vs. Laravel

I agree with Simone, Symphony to me is the philosophy of reusable content and never assuming anything on the frontend. XML/XSLT is a bonus, something that I love and won't stop using, but I think we could share the additional benefits of Symphony, with a greater community if this barrier was removed.

Well Said. @Nils also puts it very well in working 'with' Symphony. I got attracted to Symphony for what you could do with it, how it looked, and how you could work with it. XSLT was (originally) just the price to pay for having those benefits. ;) Obviously it shows it's power over time.

I totally agree that having a plugin template layer would keep everyone happy and that in itself would be a very unique feature which would appeal to many.

With regards to choice of framework with Composer in the picture it's not as big a decision as it used to be. You can still grab whatever packages are compatible from any other framework. And Laravel is just sexy to work with. :) Version 4 has pretty much seen it reach maturity now and Taylor himself has said he doesn't seem any more mass rewrites for a long while. It just needed to take big strides in getting to the top. As @iwyg mentioned, release cycles for point releases will be 6 months.

So with a well documented outsourced core in Laravel attracting developers, a hot-swappable template layer for XSLT, Twig, et al. appealing to front-end designers/developers, and all the benefits of Symphony in the middle appealing to users I think I just imagined my perfect CMS. :)

I think I just imagined my perfect CMS. :)

Welcome to my dream!

Let's make it happen! We're going to need an architect... and a powerful sedative.

so, any volunteers?

I requested emails from interested parties quite early in this thread, and I've only received two so far. I have also (today) sent an email to all those registered in the working group to ascertain involvement so we can sort out access rights, and also start discussion on how we tackle this project.

Seriously, if you want to be involved, you need to email me at john@designermonkey.co.uk, that way I can sort things out with Brendan, the Working Group and of course Allen.

You're right. My apologies. I'm trying to sort things out this week. I'll also have to talk to Allen, but you probably can count me in.

No need for apologies! Not at all!

Can you mail me too, as I don't have your address.

So, there will be Laravel-based Symphony?

We're still waiting for feedback from Allen, on a few channels before we can say a definite yes or no.

was busy/offline for a few days and this thread just unravels.

The concept is quite interesting I haven't been following Laravel as much but having a Long-Term plan is essential for the continued development of Symphony.

As Brendo said it could probably free up plenty of his development time, to focus on what Symphony is all about. I've been messing quite a bit with extensions creating custom extensions/datasources and I find the Symphony API extremely simple to work with.

For me XML/XSLT is part of what makes Symphony so simple to use in development/design terms. It just makes templating so easy and clean. Having the option of plugging in other templating layers would maybe attract more users but I would still think that XML/XSLT should be the base. If other developers like the flow of work I'm sure that they would still give it a shot, or try plug in their templating layer if we provide an interface for that to happen.

@designermonkey I would like to start contributing in some way to the new Symphony in my limited time.

@designermonkey, I've responded to your e-mail. Thank you for following up with everyone!