Let's consider I have different projects for my company. What is the best practice concerning symfony 2 ?
1. Add new bundle for each project in the same symfony 2 skeleton (there could be several bundles for one project: even shared bundles between differents project)
2. Add a new Symfony 2 skeleton for one project (there could be several bundles for one project)
if way number 1 is acceptable, is there a maximum number of bundles for one symfony 2 skeleton ?
A Bundle is a logical component in your website like a backend or a menue. You should build your bundles global that you can use it in new projects.
I would prefer to make more instances and build bundles that were included in your projects (vendor folder). Then you have single components and can use it in new projects.
The advantage is that you can have different versions in different projects. Perhaps you need another version of a bundle in Project A and Project B. Thats its a bit complicated with one instance.
When need to scale your website its better to have more instances to put it on different servers. When you have only one instance with all projects then you need everytime the complete sources.
You can build your own composer packages to update and deploy over composer.
https://packagist.org/
I think there are some more package builder.
Related
The question:
Is a Symfony 3.4 project created with the Flex installer really Symfony 3.4? Or more a "Symfony 4 project with 3.4 core files?
The complete story:
I am working on migrating an existing Symfony 2.8 project to Symfony 3.4. At first I created a new Symfony 3.4 project using the Symfony installer:
symfony new MyProject 3.4
The file and folder structure is a bit different to Symfony 2.8 but overall everything is quite similar. It was not too difficult to migrate the config, files, etc. from the existing 2.8 project.
However, after some more research I thought it might be a good idea to start the new 3.4 project using the recommended Flex installer instead. This would give me the new folder structure which is also used in Symfony 4, which might make a future migration to this version easier.
composer create-project symfony/skeleton:3.4.* MyProject
Of course the directory structure is different in this project. But not only the folders are different but almost everything. The way the complete config is organized, how the routes are defined and managed, how bundles are organized (none at all), how parameters are defined and used, etc.
There is almost nothing left that looks like Symfony 3.4. This seems to be a Symfony 4 setup where only the files in vendor/symfony/... are from version 3.4
Migrating the 2.8 project to this setup would be way more complex.
Of course I know that a lot has changed in Symfony 4 while Symfony 3.4 is still quite similar to Symfony 2.8. But how is it possible that two Symfony 3.4 installations are so dramatically different?
I understood that Flex is a new workflow to manage projects but shouldn't be the end result - a new Symfony 3.4 project - be more or less the same no matter which workflow / install was used to create it?
Flex is more powerful when setting up and managing different project. However I want to setup the project once and run it for several years. Is there any advantage (in the near future) in proceeding with the Flex approach?
To answer your first question: Yes, a Symfony 3.4 project created using Flex is indeed a 3.4 project. "bin/console --version" will verify this.
As far as the directory structure goes, Symfony tries to strike a balance between maintaining backwards compatibility but at the same time keep moving forward and refining their design. For information on why things were done, it is useful to keep an eye in the Symfony blog and perhaps visit the slack channel. Especially the posts when Flex was introduced as well as the new directory structure.
One goal for Symfony is to make it as easy as possible to migrate from a long term support version to a newer version. Hence 2.8 is pretty much identical to 3.0 except that a bunch of depreciated functionality was removed. If you were following things at the time you would have noticed that there was quite a big jump between 2.7 and 2.8.
Same for 3.4 to 4.0 being easy but a few possible bumps going from 3.0 to 3.4.
Kind of meandered a bit. Sorry.
To address your second question of the value of using Flex, like all opinion based questions the only correct answer is: it depends.
In my case the choice to use the new directory structure was easy. I have a number of apps and use Symfony on a daily basis. Keeping up with the latest and greatest makes sense for me. Spending the time to port apps (some of them dating back to 2.3) to 4.0 makes my overall maintenance burden easier. The time spent experimenting how to port helped me understand the new functionality. Once I got comfortable with the process it was really just copy/paste/rename exercise for the most part. The hardest was making sure some of the 3rd party dependencies were properly updated.
In your case, it seem like you only have one app and you just want to get it updated and then forget about it for a few years. In that case, keep the old structure and move on. At some point you might need to move to the new structure but waiting a few years won't hurt anything. And hey, I suspect 5.0 will introduce more changes.
The choice is yours.
Symfony Flex is the new way to install and manage Symfony applications. Flex is not a new Symfony version, but a tool that replaces and improves the Symfony Installer and the Symfony Standard Edition.
Symfony Flex automates the most common tasks of Symfony applications, like installing and removing bundles and other Composer dependencies. Symfony Flex works for Symfony 3.3 and higher. Starting from Symfony 4.0, Flex should be used by default, but it is still optional.
Source : https://symfony.com/doc/3.4/setup/flex.html
So, I have an application that consists of 5 different projects.
Each of the projects is a new Symfony 4 project, since I need to host them on separate domains.
My structure is like this:
Admin project: /var/www/html/admin
Client project: /var/www/html/client
Owners project: /var/www/html/owners
Each of the project has its own symfony skelet (src,public,config,bundles,public, etc...)
I know this can be done through bundle, but, what I want to do is to create a new Symfony project (Common) and use it accross all the others. Since ill be having same entities and same common services through projects, I need to include it in each of them.
Is there a way to include this Common project into all others and use services/entities from there?
I have a home-made framework which contains two types of bundles. Application bundles and dependencies. Application bundles are specific to the application (can be a news module, administration, etc.). Dependencies are libraries which I re-use in several projects.
For every new project, I start by adding the app bundles and dependencies. Until now I kept a separate copy of these bundles and copied them manually into my project.
I rarely need to modify dependencies. However with application bundles, I always have to customize the views and controllers, so they are meant to be modified in all the projects they are used.
I want to improve the way I manage these bundles and thought of using Composer. However, it does not comply very well with the application bundles, as you are not supposed to modify the packages. I would need to be able to install packages for once, then ignore them in the next updates (they become part of the application source code).
I could add some override mechanism (copy classes to another directory, which would override the default bundle classes) as Symfony does I think, but I don't like this idea. It just adds unnecessary complexity.
Could use another bundles management system, or even a custom one, but then this means no access to Composer packages, which would be great.
Using Composer for dependencies and another system for the application bundles would be messy..
How would you handle it?
It it should run on unix, use apt, yum, yast ...
Simply try to build your own dep / rpm pakages.
Build foreach application bundle and depencencies bundle.
That add at theapplication bundle the depencencies bundle as depends.
Or do you looking for something like pear?
Can you direct me to some tutorials or helpful information regarding Symfony2 and common components among similar projects? I have two projects that will use a tremendous amount of the same code (mostly backend logic/user handling/checkouts), but there will be quite a different in the frontend templates, display and functionality.
Currently I have three folders with symlinks (Project 1, Project 2, and Symfony Base). Is this the best setup? Recommendations for doing it better?
Symfony 2 Bundles are what you want here. Wrap up all the stuff you want to share between projects in a bundle installed in to both - then build the project specific UI on top of it.
Would recommend on the Symfony 2 docs: http://symfony.com/doc/2.0/cookbook/bundles/index.html
I'm just working through the Symfony2 Bible and I'm a little stuck on the bundle system. It is a great feature but I'm not quite sure how to split my flat PHP application into bundles. It's my first time splitting my PHP code into a full featured MVC framework.
I'm working on a few online games (based on PHP) but how would I define the bundles ? Is it like one single onlinegame1 bundle with all the controllers and functions - Or like a login bundle, a register bundle, a war bundle - summarized one bundle for every single PHP file I got ?
I want to start clean and correct but I'm not quite sure if I understand that feature.
You could think of bundle as an independent reusable component - in most of the cases at least.
Let's imagine a personal blog website. I'd split it into ArticleBundle, UserBundle, CommentBundle and finally MainBundle which would stick all these other bundles together, creating your website. The main point is that you can take for example ArticleBundle and reuse it easily on other project without it being tied to any other bundle.
From Symfony2 book:
A bundle is similar to a plugin in other software, but even better.
The key difference is that everything is a bundle in Symfony2,
including both the core framework functionality and the code written
for your application. Bundles are first-class citizens in Symfony2.
This gives you the flexibility to use pre-built features packaged in
third-party bundles or to distribute your own bundles. It makes it
easy to pick and choose which features to enable in your application
and to optimize them the way you want.