Introducing the Symfony Demo application
Today we're glad to officially introduce the Symfony Demo application. This project is a fully-functional Symfony application developed as a learning resource. The application deprecates the old AcmeDemoBundle and it can be considered the reference implementation of the Symfony Best Practices.
Technically, the application consists of a blog engine with both a public and a private section:
The private section is a simple CRUD backend developed from scratch:
Every application page includes a Show Source button which displays the Symfony controller and the Twig template used to render the current page:
In addition, the source code of the application contains tons of comments to help you better understand why and how things work.
How to install the Symfony Demo application
Open a command console and execute the following command anywhere in your system:
1
$ symfony demo
This command leverages the Symfony Installer to download and install the demo
application. If the demo
command doesn't work, update your old installer
version executing symfony self-update
. Once the demo application is downloaded,
use the built-in web server to run it:
1 2
$ cd symfony_demo/
$ php app/console server:run
The Symfony Demo application is designed to run out-of-the-box, so you won't need to configure anything or run any other command. Alternatively, you can get the demo application through the symfony/symfony-demo repository.
What is this application useful for?
1) Learning Symfony
This is the most obvious reason to use this demo application and its main purpose when we developed it.
2) Teaching Symfony
This application can also be a useful teaching resource to train your company interns and to deliver workshops during events organized by the Symfony community.
3) Testing new Symfony features
Do you want to test the great features introduced by a new Symfony version without messing your applications up? Install the demo application, update the Symfony dependency and you're done!
For example, you can test Symfony 2.7 beta features as follows:
1 2 3
$ symfony demo
$ cd symfony_demo/
$ composer require symfony/symfony:2.7.x@beta
4) Relative benchmarks
The demo application is developed as a learning resource, so you cannot use it in a performance benchmark. However, it can be used to do relative performance benchmarks.
Install a fresh new demo application and profile it with Blackfire. Introduce some changes in the application and profile it again. You can now visually compare both executions and check out how much the application performance improved or degraded.
Help the Symfony project!
As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.
Comments
Comments are closed.
To ensure that comments stay relevant, they are closed for old posts.
I like AcmeDemoBundle, but Symfony Demo application seems more interesting at first sight!
congratulations to everyone involved
@Jacek we needed to do some things to make it work out-of-the-box without executing any command. We'll improte it in the future. In any case, the error is not critical for the end users of this application because they never see the repository.
@Niels as a matter of fact, the best practice states that templates should be stored in app/Resources/views/. You can read the explanation in http://symfony.com/doc/current/best_practices/templates.html#template-locations
First of all, you see a basic example of bad code, where entities are being populated and saved directly in a controller (https://github.com/symfony/symfony-demo/blob/master/src/AppBundle/Controller/BlogController.php#L78). A good solution for that would be split these two different actions into Hydrators – to populate the entities – and Managers – to save them abstracting the persistence layer away (yeah, here you're coupled to Doctrine's entity manager).
Another problem is forms being created on the fly, directly on the controllers (https://github.com/symfony/symfony-demo/blob/master/src/AppBundle/Controller/BlogController.php#L126). Symfony allows you to do that, and that's very, very good. But that doesn't mean you should be doing it. Keep your form implementations separate – really, really far – from your controllers. Each form can have it's own implementation and even each field for that matter. On a basic example like this, that might seem a bit of overhead, but trust me: most applications tend to grow fast and this is a very bad example to follow.
One more example of weird practice would be the definition of an AppBundle that holds the entire application. Come on? We're passed that since a long time now. Bundles are supposes to integrate thirdy-party libraries into Symfony and add functionality on top of that. Let's not put our code into bundles, that doesn't make sense. Unless, of course, you want to be coupled Symfony's structure from the beginning.
Well, at least the layout looks nice.
The bottom line for me is: to find out about best practices with Symfony, try to follow successful projects on top of that framework, such as Sylius and so on. Even Sylius has its problems, but at least the community is aware of them and is trying to find solutions for those.
>> ...
>> We'll add that pagination example soon.
@Javier Will you want to use KnpPaginatorBundle for it or implement your custom simple pagination?