Symfony: how to get started
The more I work on my first project at work, the more I want to change it and the more I regret that before starting work I didn’t read “ The Definitive Guide to Symfony ” and didn’t learn about symfony plugins . Many of them would help me a lot to reduce development time and, most importantly, not to think about how beautifully to implement these or other things ... And one more thing - if you already have a piece of the system (as I did), which you are going to rewrite using your framework (or simply rewrite, because you don’t like the code) - then my advice to you is to take the time to design this piece on the plan of your new system, don’t rush to rewrite everything (I confess that I did so), since after analysis (which, in Possible, will take you more than one day, or even one week), possibly from the previous architecture of the system will be over.
In general, I like to design, think over, analyze these or other solutions that I want to implement in the system (although, I confess, I have little experience in this), but how can I explain to the customer that you spent the day thinking ... Oh ...
Okay, I digress. Today I want to talk about where to start when developing a system using symfony and what rules should be followed.
Actually, it all starts with the creation of a project (project) and applications (applications) in it. How this is done can be read in the book (the link is given above), and I would like to dwell on the explanation of what the project is and the principles for choosing applications in it - what names to give them, how to structure them, etc.
As I understand it, in general, it is assumed that you will have one project for the entire site, and it will be a kind of repository of applications, configuration files and models that all applications of this project will use.
Unlike Django , here the application is not an atomic unit of the system that can be used in other projects ... In Symfony, they are created only to logically (well, physically) differentiate the functionality of your project. And most importantly - the applications are taking place only within one project. Those. if you delete one application within the project, others will not suffer from it, but transferring from one project to another will be very problematic, since it depends on the project settings, on the project model, and so on.
It would not be superfluous to say that it is officially recommended (to read as “proposed”) in the project to create two applications: frontend and backend (for the Russian-speaking audience, the term “admin” will be more appropriate in this case). I myself can recommend creating applications only for combining modules that have one goal in front of them. For example, the same admin, user interface (that is, for example, a user profile, everything that a user can change on the site) and frontend (everything that is accessible to everyone).
I myself use the recommendation of the book and have two applications in my project.
I do not want to consider the pros and cons of this approach. Let me just say that for me the Django approach is much more convenient and logical, and these projects / applications for a beginner look quite difficult and incomprehensible, in most cases, beginners simply listen to the recommendations of the book, not quite understanding what it is and why it is needed. I’d be at the site of the symfony developers would have thought about revising this approach, especially if we consider that the symfony plugins are essentially the same Django apps, but more on that later.
Stop on the environments do not particularly want. It is very convenient, but at the same time a very simple mechanism that provides the ability to log into the same application with different server settings. If it is simpler to say - imagine that you have applications and a check mark that switches its mode of operation to debug-mode and back. In debug-mode, for example, all events are logged, all errors are displayed on the screen, etc. If debug-mode is turned off, all logs are turned off, and there will never be any errors on the screen. So, in Symfony, instead of the debug /non-debug flag, there are just several different environments, each of which can be configured FULLY, that is, it is not the system that decides what to turn on and what to turn off, but you yourself. I would also like to note that you don’t have to dig particularly in the settings - by default, 3 environments are created for each application: production, development, testing (used exclusively for testing).
In general, there is nothing to complain about - everything, in my opinion, is just perfect.
... contain a controller with actions and views (ie MV from MVC ), as well as configuration files and, possibly, libraries, needed only in this particular module. Everything is quite simple and understandable.
Modules (like applications with a project) can be created automatically (and using the command line). In addition to creating a simple module, you can create (again - automatically) CRUD ( Scaffolding ) for one of the tables, or an admin panel (again, for one of the tables). The admin panel is different because there is almost no need to write any code - almost everything in it (filtering, sorting, etc.) is configured using the configuration file, which is VERY convenient (hello to the jungists, they will understand). CRUD is very useful during the initial stages of development. Example - you added a user table, now you need to: display a list of users, allow them to edit their profile and register. Instead of writing everything from the very beginning, we create a CRUD module for the user table, and then we can begin to write our code based on the already generated one. The implicit plus of such a solution is that the codes of the modules are similar to each other and there is less confusion.
The last thing I would like to dwell on is ...
All models are stored in one (or several) YAML files. You get used to writing models in3-4 days. From YAML model using a single command is converted into automatically generated base classes ORM ( Propel or Doctrine ). Everything is fast, simple and neat.
')
Perhaps this is all that a newbie might need when learning about symfony (so that it does not seem to him to besome kind of complex and incomprehensible system that it seemed to me a year ago).
And now let's go directly to my recommendations. But before that, I will tell you about ...
Plug-ins are, in fact, the code that can be used several times in different projects and applications. Plugins may contain:
I may be wrong, but it seems to me that plug-ins are mini-projects of their own, “all in themselves”, which compares favorably with Symfony applications. In my opinion, it was worthwhile to make a bet on them first of all - remove applications, and instead install plug-ins and create some tool that would allow these plug-ins to be interconnected.
Here, perhaps, that's all for today. Waiting for your comments.
Crosspost on my blog.
In general, I like to design, think over, analyze these or other solutions that I want to implement in the system (although, I confess, I have little experience in this), but how can I explain to the customer that you spent the day thinking ... Oh ...
Okay, I digress. Today I want to talk about where to start when developing a system using symfony and what rules should be followed.
Actually, it all starts with the creation of a project (project) and applications (applications) in it. How this is done can be read in the book (the link is given above), and I would like to dwell on the explanation of what the project is and the principles for choosing applications in it - what names to give them, how to structure them, etc.
Project
As I understand it, in general, it is assumed that you will have one project for the entire site, and it will be a kind of repository of applications, configuration files and models that all applications of this project will use.
Applications
Unlike Django , here the application is not an atomic unit of the system that can be used in other projects ... In Symfony, they are created only to logically (well, physically) differentiate the functionality of your project. And most importantly - the applications are taking place only within one project. Those. if you delete one application within the project, others will not suffer from it, but transferring from one project to another will be very problematic, since it depends on the project settings, on the project model, and so on.
It would not be superfluous to say that it is officially recommended (to read as “proposed”) in the project to create two applications: frontend and backend (for the Russian-speaking audience, the term “admin” will be more appropriate in this case). I myself can recommend creating applications only for combining modules that have one goal in front of them. For example, the same admin, user interface (that is, for example, a user profile, everything that a user can change on the site) and frontend (everything that is accessible to everyone).
I myself use the recommendation of the book and have two applications in my project.
I do not want to consider the pros and cons of this approach. Let me just say that for me the Django approach is much more convenient and logical, and these projects / applications for a beginner look quite difficult and incomprehensible, in most cases, beginners simply listen to the recommendations of the book, not quite understanding what it is and why it is needed. I’d be at the site of the symfony developers would have thought about revising this approach, especially if we consider that the symfony plugins are essentially the same Django apps, but more on that later.
Environments
Stop on the environments do not particularly want. It is very convenient, but at the same time a very simple mechanism that provides the ability to log into the same application with different server settings. If it is simpler to say - imagine that you have applications and a check mark that switches its mode of operation to debug-mode and back. In debug-mode, for example, all events are logged, all errors are displayed on the screen, etc. If debug-mode is turned off, all logs are turned off, and there will never be any errors on the screen. So, in Symfony, instead of the debug /
In general, there is nothing to complain about - everything, in my opinion, is just perfect.
Modules
... contain a controller with actions and views (ie MV from MVC ), as well as configuration files and, possibly, libraries, needed only in this particular module. Everything is quite simple and understandable.
Modules (like applications with a project) can be created automatically (and using the command line). In addition to creating a simple module, you can create (again - automatically) CRUD ( Scaffolding ) for one of the tables, or an admin panel (again, for one of the tables). The admin panel is different because there is almost no need to write any code - almost everything in it (filtering, sorting, etc.) is configured using the configuration file, which is VERY convenient (hello to the jungists, they will understand). CRUD is very useful during the initial stages of development. Example - you added a user table, now you need to: display a list of users, allow them to edit their profile and register. Instead of writing everything from the very beginning, we create a CRUD module for the user table, and then we can begin to write our code based on the already generated one. The implicit plus of such a solution is that the codes of the modules are similar to each other and there is less confusion.
The last thing I would like to dwell on is ...
Models (models)
All models are stored in one (or several) YAML files. You get used to writing models in
')
Perhaps this is all that a newbie might need when learning about symfony (so that it does not seem to him to be
And now let's go directly to my recommendations. But before that, I will tell you about ...
Plugins
Plug-ins are, in fact, the code that can be used several times in different projects and applications. Plugins may contain:
- configuration files, including their models (!!!)
- modules
- libraries
I may be wrong, but it seems to me that plug-ins are mini-projects of their own, “all in themselves”, which compares favorably with Symfony applications. In my opinion, it was worthwhile to make a bet on them first of all - remove applications, and instead install plug-ins and create some tool that would allow these plug-ins to be interconnected.
My recommendations
- First of all - design. Do not skimp on this step, analyze and clarify incomprehensible points at the customer.
- Seeing in front of you (yes, even in your mind) the layout of the system - think about which parts of the system can be broken.
- Look for such parts among existing plugins ( required ). I used the following plugins in my project:
- sfGuardPlugin - user management, security, etc. Plugin - must have.
- sfDateTimePlugin - very convenient work with dates and time
- sfPropelAlternativeSchemaPlugin - useful when working with plugins, allows you to change models written in plugins without changing the codes of the plugins themselves
- sfPropelApprovableBehaviorPlugin - it was very useful to me when “activating users”
- sfThumbnailPlugin - image reduction (do not look at the name - with the resize of
3MP photos to 800 × 600 the plugin copes perfectly) - sfPropelActAsTaggableBehaviorPlugin - if you need tags
- sfPropelActAsSluggableBehaviorPlugin - if you need slugs (and I advise you to use them - it has a very good effect on the readability of urls when you put slugs on them instead of id)
- sfPropelActAsRatableBehaviorPlugin - ratings, pretty cool, I, unfortunately, did not fit ...
- sfPropelActAsCommentableBehaviorPlugin - everything you need for comments
- Use in work automatically generated CRUD-modules and modules for admin
Related Links
- Excellent series of posts on symfony 1.1 Form Framework
- Symfony blog
- The Russian-speaking Symfony community (in my opinion, if you are more or less normal with English, it's better not to go here at all).
- It is best to read the symfony book in Russian here (there are several translations, as I understand it, one of them is on the above site, but here is the most complete).
Here, perhaps, that's all for today. Waiting for your comments.
Crosspost on my blog.
Source: https://habr.com/ru/post/20814/
All Articles