Symphony.

Greetings all.

First, a very quick update on my recent disappearance. For those that knew about my situation, I'm now back in Australia permanently after three years living abroad. I've only just arrived in Australia this past weekend. Apologies for the delays to your queries, John, Mark and Stephen, dealing with immigration took up all of our time and energy for the past month or so. I still owe Stephen a new server environment, which is two weeks past due (sorry!)

Now, on to the discussion surrounding Symphony + framework. In summary, I am for this.

Symphony's strength is in our approach to solving the CMS problem, and to this day I believe the philosophy and culture we've built around this aspect is still Symphony's main attraction.

We had originally created our own architecture because we had to facilitate what we needed Symphony to do (note that coding frameworks were only just in its infancy back then). This was bred out of necessity, not out of our own volition. Our architecture had always been in service of our design guidelines and not the primary drive of our development effort.

I think this is why it's evident that while Symphony has framework-like qualities, the essence of Symphony is still rooted in a CMS.

Ultimately, Symphony's development team should not concern themselves with solving programming framework problems. We need to focus on our core competency.

With regards to XML/XSLT, it's important to note that Symphony's identity and the origins of Symphony's unique approach to CMS came from XML/XSLT. The influence it has is critical to Symphony. That said, while the concepts of XML/XSLT is vitally important, the language itself isn't.

I absolutely adore XSLT. I is still my favourite templating language currently available. However, this isn't due to the fact that I am precious about the language, but rather I have yet to find a language that approaches the power and elegance of XSLT.

All this is to say that the concepts of XML/XSLT defines Symphony, but if the templating system is replaced with something else in the future, that doesn't necessarily mean we also lose the identity of the system.

What does it mean for Allen, and Soario?

Taking a huge leap towards a new codebase was what I wanted to see in Symphony 3. We didn't go with a framework in our previous attempt as we didn't find a framework that was mature enough or suitable but I think the web and programming landscape today is very different to what it was a few years back.

Soario, as a company is invested in the longevity and growth of Symphony. As such, this is only a good thing.

Another issue with Symphony is that since when Alistair abandoned it, Symphony has lost its stability. If I were asked to explain my statement with a picture, I would draw a straight line vs a broken line. The evolution of Symphony is now a broken line. There's no clear direction, no bias, no vision.

I think the connotation that Alistair abandoned the software is a little dismissive of the work he's done for the project. He has indeed moved on to other things, like finding a stable job (as a law enforcer) to provide for his family. I think using "abandon" to colour contributors moving on from the project doesn't give people the credit they're due.

The rest is, in my opinion, due to the fact that apart from @brendo no one else is officially entitled to be the main developer of the platform. Ideally, we should have some two or three core developers that set the pace, take care of the vision, review pull requests and agree upon a few coding/design guidelines for the platform (I have seen some issues on GitHub addressing this last problem, which is great.)

It's not that "no one else is entitled". No one else has yet stepped up to take this on. I'm sure Brendan would love to have more help here.

I'm really glad to hear you're home Allen, I know it's been a stressful three years and can only hope it's getting better. On behalf of the community, welcome home :o)

I have had a few responses from my request for offers; Some of positivity, and sadly a few who have left the working group. I'm currently waiting on a few responses from current members, and any tails in new offers before I compile the full list. Once done I will try and arrange a date we can all chat together to get some ideas down.

I will definitely be stepping up to do some work, but my time will start off in Documentation with Stephen (@bauhouse) to ensure we have a solid set to work from. To make this work, we need to reproduce our current admin and concepts on a new framework, and to ensure that we hit the mark there before new features, it must be documented at least from a users perspective.

Whether that is available on a website to start with or not, it will definitely be in a repository for anyone to read through and send pull request adjustments too (my spelling can be crap).

I am already generating ideas on how we can approach this, but I need to discuss these at length with Allen and Brendan, but I will get these written down at some point soon.

I will be getting interrupted with a new baby very soon (overdue), but will do my best to keep on top of most of this.

First, a very quick update on my recent disappearance. For those that knew about my situation, I'm now back in Australia permanently

I'm happy to hear that you are back in Australia with your family. And here I thought your silence was a result of you organizing a kangaroo hit squad for starting the discussion ;)

Now, on to the discussion surrounding Symphony + framework. In summary, I am for this.

I believe this brings discussion of if it's a good idea to a close. The thread appears overly supportive of the idea. I believe the next step is a working group to choose the right framework to move forward and build Symphony 3.

Another issue with Symphony is that since when Alistair abandoned it

I'm glad Allen commented on this because I previously overlooked it. You are entitled to your opinion but make no mistake that Symphony wouldn't exist today if it wasn't for Allistair's hard work.

Symphony has lost its stability. If I were asked to explain my statement with a picture, I would draw a straight line vs a broken line. The evolution of Symphony is now a broken line. There's no clear direction, no bias, no vision.

And to say that the line is "broken" with Brendan supporting the core is incorrect. I'm surprised you're not more grateful for his dedication and contributions to Symphony 2.

Allen, I am glad to hear that you have landed safely in Australia this past weekend. I appreciate you taking the time to address the questions and comments in this thread.

I am also glad that you spoke up in defence of XSLT as one of the core differentiators of Symphony. 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.

I have more to say about the move to a different framework that I might like to add, but it's probably off topic, so I'll start another thread: How to grow the community: a Symphony approach.

@Allen glad you're back home.

Having your say on this 'new direction' so to say was quite important, as long term support & planning is essential for Symphony to keep thriving.

I think that this comes back to the discussion we had in the last Symposium where we where trying to place Symphony in the Framework/CMS spectrum. With the community agreeing what Symphony is we're able to make the next jump.

I think using "abandon" to colour contributors moving on from the project doesn't give people the credit they're due.

You are entitled to your opinion but make no mistake that Symphony wouldn't exist today if it wasn't for Allistair's hard work.

I'm surprised you're not more grateful for his dedication and contributions to Symphony 2.

I respect (and am thankful to) both Alistair and Brendan for their hard work, a lot. I esteem them and have nothing against them. I may have picked the wrong word(s) (remember, English is not my native language and I do not know all the nuances of meaning), but I never stated that it's Alistair's fault or that I do not appreciate what Brendan's done so far.

Next time, please ask for clarifications before jumping to conclusions.

No one else has yet stepped up to take this on. I'm sure Brendan would love to have more help here.

I'm sure too. Also, I think that moving to Laravel is not feasible without at least a couple of extra (paid maybe?) developers.

I'm currently working on a xslt templating bridge for laravel 4. Works well so far.

I'm quite busy next week but maybe I'll find some time to work on it this weekend. So if anyone is interested, let me know.

I'm currently working on a xslt templating bridge for laravel 4. Works well so far.

I've tried to give it a go as well; didn't come too far. Do you have something to show off? ;-) Apparently, there was once a array_to_xml method in Laravel, it seems to be gone though.

There's a Composer package DOMi that I looked at recently. May be of some help.

Okay, this thread started with Laravel and in the end we agreed to move to a framework.
So which frameworks are actually in the game? Which are suitable? And why?

Mentioned so far:

• Laravel
• Symfony
• CakePHP
• Zend

By the way, when we talk about Laravel, are we talking about this or that?

By the way, when we talk about Laravel, are we talking about this or that?

Talking about that. Laravel 4, which will be released in May.

laravel/laravel develop branch is Laravel 4; master branch is 3.

From Installing and updating Laravel 4:

I’m not sure how people are currently doing this, but I get the feeling a lot of people are cloning the laravel/framework repository. There’s no need to do that. The laravel/framework repository contains the components that will be placed in vendor/laravel.

laravel/framework is where bugs/issues should be discussed.

Talking about that. Laravel 4, which will be released in May.

No. The other one. :-D

Laravel consists of a lot of different modules, plugged together using composer. laravel/framework is just one of those components.

laravel/laravel on the other hand contains the basic skeleton of things you need to run an installation of Laravel and will install laravel/framework as a component.

This means that in essence "symphony X" would also become a composer-component and will be installed side by side with laravel/framework.

Do you have something to show off? ;-)

Nothing really yet, but if you are interested, you can try it out (and/or contribute).
Repository is here: https://github.com/iwyg/xsltbridge

Sorry, it's lacking of documentation, but I have currently no time to work on it.

Thomas, can you send me your email please :)

done :)

No. The other one. :-D

Readme said Laravel 4 Beta. So I'm not entirely wrong... ;)

Damn it. It's totally broken on the Beta release.