Symphony.

I often get asked why I love Symphony so much when I work on new projects.

I am a front end developer and often find myself having to argue for Symphony against the frameworks mentioned above. One of the main sticking points is that PHP developers I have come across prefer to work solely in PHP and see no need for XSLT. I often try to explain that the PHP is the logic that drives the System and that the XSLT allows me to use the data provided to me and thus transform to deliver in not only HTML but also RSS, XML, WML etc...

Additionally, XSLT is a functional programming language, and doesn't need to do the extra logic that PHP would need to. That middle ground is covered pretty much by Symphony itself.

After said argument, I find myself alone and sometimes find it hard to convince internal teams and sometimes clients. I recently had this issue and had to end up working with Drupal for a very large project. The developer argued his point well because he had prior experience and even said that something that looked as simple as Symphony could not deliver the kind of results required by a website with hundreds of pages and hundreds of thousands of visitors. The other frameworks also happen to have lots of thorough documentation and wide community support. I know we have a very dedicated and supporting community here, but i couldn't convince him that he had all he needed to extend Symphony. I explained that the beauty of Symphony is you don't need to hack it at all, you build upon it, to which I got "so does Druuupalll...".

So I guess my question is, how does Symphony stack up against the above mentioned frameworks and what would be the major selling points of it? I love Symphony and would really like to work with it more often. And moving on from this, am I right in saying that Symphony 2 is the kind of framework that goes beyonf making websites and is just as powerful enough to use for making web applications? I have seen some concepts flying around recently and just wanted to throw that in as a potential selling point.

Thanks

I think you're comparing apples to oranges here. Symphony isn't a framework, although it does have the ability to be extended via campfire services. Symphony is a content management system, and as such it allows you to store, retrieve, manage, and display data.

Cake and CI are frameworks, which mean that they give you the tools needed to code applications faster and easier. Comparing Symphony to Drupal would be more accurate, I think, but I've never used drupal personally so I can't say for certain.

I think you're comparing apples to oranges here. Symphony isn't a framework, although it does have the ability to be extended via campfire services. Symphony is a content management system, and as such it allows you to store, retrieve, manage, and display data.

Symphony is not a code framework, but it is arguably a framework. Every application I can think of shares a common purpose of managing content. Code frameworks are a means to this end.

Symphony has the basics of a framework. You have all these bits and pieces (i.e. sections, fields etc.) that can be put together different ways to achieve different outcomes.

Symphony is a CMS with a heart of a framework.

Ok, so Symphony is a CMS not a Framework. Yet it's flexible enough to provide the basics of a framework through campfire services. All clear now, I guess my terminology wasn't clear enough.

So going back to my question, which would you choose in order to build a web application? I can see how a Framework provides the tools needed for web applications.

However am I correct in saying that Symphony can also provide the same flexibility through the creation of Campfire services in order for you to build a web application?

I can see how Symphony would allow someone to capitalise on this and offer Campfire services as commercial plugins or reusable open source code. nice.

If I was building a simple website with a limited number of users, and a limited need for custom data interaction, I would choose symphony. If there was a lot of unique, custom stuff, I'd probably choose CI or my own framework that I'm developing.

I used drupal once a few years ago. i thought there were some limitations to it. but to put it in perspective, I didn't know nearly as much as i do now. but to say the least, i haven't gone back to it. symphony is the only cms i've used that I've stuck with for this long.

I think different technologies have different shining bits. For Symphony, those bits are: data interpretation, format transformation and content management.

Symphony would be a great platform to power web applications such as financial bookkeeping, invoice generator and project management.

Financial bookkeeping apps require data interpretation such as summations, tax application and deductions.

Invoice generation apps require the data to be transformed to different formats: HTML, PDF and CSV.

Contact management apps require managing content through lots of sections working in relation to one another.

Symphony on the other hand may not be the best at social-focused websites (facebook) or content pushing sites (youtube).

Massively social websites require complex and intricate relationships that only dedicated data structures can provide efficiently. Content pushing sites require dedicated horsepower that requires grid-based systems for load-balancing. Symphony is currently an one-machine system.

When discussing the definitions of content management system and frameworks, everyone has a different interpretation. But at least I think most people can agree that there are overlaps to the terms and I think Symphony sits squarely in it.

Nice summation, Allen.