I'm planning to write an AJAX extension for the forms in Symfony3. I want to be able to use ajax requests in many forms instead of submissions.
Now I don't understand the exact relation between Bundles and Services.
As I understand it to write a service is the right way to do so. At the same time I want to make my code reusable, so I can use it in further projects.
My extension needs to have some JS and TWIGs I guess.
So, is the right way for deploying my service to encapsulate in a bundle? Or are they bundles theirself? Or can they be deployed without encapsulating?
If you want to make your code reusable, you need to make your bundle configurable, basic steps to achieve it:
Create a bundle:
http://symfony.com/doc/current/bundles/SensioGeneratorBundle/commands/generate_bundle.html
Making it configurable:
http://symfony.com/doc/current/cookbook/bundles/configuration.html
You need to put it in another repository and read it later using git submodule or packagist, depending on your strategy or if its private or not.
This steps will means your bundle cannot depend of any class internally created in your project, I would recommend to you to check some other bundles around.
A good example can be the Tactitian bundle, which integrates the League Pipeline library into SF https://github.com/thephpleague/tactician-bundle
In this code you can see how they configure the library and create the services around it!
I hope this helps you!
Related
I just started with symfony 4 and have a question about "multi-controller", if my application got many routes, should i go for more controllers to keep the files tiny and readable or is one controller enough / recommended?
There is no recommended way about multi-controllers on the official documentation.
If multi-controller is a good choice, how to split?
If there a good documentation on the inet?
Absolutely yes, you should have more than one controller. Symfony's best practices recommend to keep your controllers tiny and delegate much of your application logic to services that you create to handle different actions. For this, it is essential that you have a basic understanding of Dependency Injection, the Container pattern and, more specifically, how Symfony's DI Container works (how you can register services, for example).
There's tons of documentation on Symfony in the intenet. This one on controllers.
KnpUniversity has some really good tutorials to get you started. Start with the Symfony series, then follow with Symfony Internals.
Also, you will greatly benefit from the features of the maker bundle, that will generate code for you really quickly. You can install it with composer require maker. Then, you can create a controller running php bin/console make:controller.
Background
We are planning to migrate our current code to a Symfony2 project.
In our case, each application is considered to be a country where we operate. As such:
Each application has a unique top-level domain.
Each application will have the same subdomains.
Each application has its own database. The database structure for each application is the same.
Applications will share the same business logic. Any differences in business logic will be abstracted into a configuration file. There should be a base configuration file that applications can override with application-specific configurations.
Applications will share most of the templates, but there may be application-specific templates too.
Possible approaches
Multiple repos
Each application would be a Symfony2 project by itself.
All development would take place in bundles, each application loading the same bundles thru composer.
This approach would make development quite cumbersome. Ideally I would like to test any changes in all countries without running composer etc.
Multiple apps within a single repo with multiple Kernels
Each application would have its own app in the app/ folder as suggested in here.
Duplicating the whole app folder seems a bit hackish. Not sure if this is a recommended practice?
Modify Symfony2 to support multiple applications
Modify the Symfony2 Kernel/Console/Whatever to support multiple applications.
Are there any existing bundles/examples already doing this?
[Your idea here]
Are there any other possible approaches?
Question
What would be the best approach to add support for multiple applications in Symfony2?
This is a fine approach but if you find you are sharing a lot of code...
The creator of Symfony2 does not recommend this practice. If you need multiple kernels, you most likely need multiple projects. https://groups.google.com/d/msg/symfony-devs/yneojUuFiqw/sZ8BZrzFLbwJ
IDK
For a project I have built the changes come from a $_GET parameter. What I do is, I have a primary project bundle that handles the common functionality and references the app/view for basic layout. Inside the "core" functionality, I created a controller and use it as a service so that all my application-specific bundles can use it at any point. Then I create a Symfony2 extension for each of my application-specific config definitions so that each application can have yml configs while keeping high-level config in app/config/config.yml. An advantage of this is that in the CoreBundle's controller I can create generic page routes and render like:
$this->render('Name'.$project.'Bundle:index.html.twig', array('params' => $params));
I'm building an app in Symfony2 that receives a HTML string via an API, does some work on it (think of something like the Tidy library, only with a different purpose) and then returns the fixed HTML.
The stuff that does all the work is mostly written in services, because they don't need to return a Response object.
Where do I store those services? I'm putting them in bundles, but there's no obvious place to store them. I understand that they can be stored anywhere, but I'm wondering what the default convention is.
If that code doesn't have to be re-usable outside of Symfony2 projects, you can just put it into your bundle.
I'd go for something like:
Acme\HtmlCleanerBundle\Cleaner\SimpleCleaner.php
Since it is a bundle, you can extract it to a separate package and re-use it for other Symfony2 projects.
If you want the code to be completely re-usable and standalone, I'd suggest you extract it to a separate library. You can still have dependencies on individual components (shameless plug: you could manage those dependencies through composer, which will be used by Symfony 2.1).
If you decide to go down that path, the bundle simply integrates the library into Symfony2 by providing DI container configuration for it.
I'm new to version 2 of the Symfony framework. I made some projects with v1 but now trying to get my head around the new version and it's features.
I read over the concept of Bundles but it's purpose is not yet very clear to me.
Say you have a big web application, a CRM for example. How would the bundles look like?
Would it be NewsletterBundle (for sending newsletters), ContactManagementBundle (for managing contacts), UserBundle (for editing users and their permissions).
Or would it be less cut-up like, EmailBundle (for handling the entire email traffic), CRMBundle (for putting in all your CRM code), PermissionsBundle, ApiBundle.
I like to think of it like this: a bundle should represent a specific feature or set of like features for a project.
Your first example is a better use of bundles than your second example, because the purpose of each bundle is more defined. While it's possible to use one CRMBundle for everything, you wouldn't really be taking advantage of Symfony's ability to organize your code. Additionally, if you wanted to port over your Newsletter code to a new project, but not all of the CRM code, you'd have an easier time copying over a NewsletterBundle versus copying over the CRMBundle, and then pruning it.
When thinking about a Symfony2 project, sometimes you want to forget everything you know about symfony 1.x, since they take wildly different approaches to solving many problems. For example, in symfony 1 it was common to build a 'frontend' and 'backend' app for a project, and each app would obviously contain logic specific to those parts of the project. So you might have a Newsletter controller in both the frontend and backend apps. In Symfony2, you're better off using only one Newsletter bundle, but with two controllers (perhaps named 'frontend' and 'backend'). Again, an immediate benefit to this is how reusable your code becomes.
I'm developing and intranet application with symfony2. I'm currently using only one fat bundle for all my features. Seem like this is what is recommended and what most symfony2 developpers do.
I wonder how you deal with an growing application where you create entities again and again. Do you just create them in your Entitiy directory inside your bundle? Do you sort them into subdirectories?
The same question can me applied to others classes like the forms.
Any advice on this?
In my opinion, even if best practices say to use a single bundle, for big project this can make you lose time.
In my projects I'm used to create :
- one bundle for statics pages and resources : for example PagesBundle
- one bundle to the member area : UserBundle
- One bundle for the core of the application : ArticlesBundle in the case of a blog, for example.
This serves to separate and save time in the tree Symfony2.
Tell me what you think.
This is a very subjective topic and mostly relies on what you are most comfortable with. The reason why the best practice now proposes just one big bundle is that the bundle approach was mainly for reusability purposes.
Some people even recommend to store entities outside of any bundle in src\YourNamespace\Entity.
Either way: subdirectories are definitely a very valuable option to sort classes.