Couple of month ago I got a legacy project written on Sf2. I fixed some bugs, and added some new functionality, but still i feel that it was made a little bit clumsy. Well, maybe not just a little :) So, I have a number of questions, how things really should be done in Sf2.
The first thing which is bothering me, is that the Application is separated on Frontend and Backend bundles. The're standing on the same model, and for example entity Book can be seen from FrontendBundle and edited from BackendBundle. In some way this is producing a confusion of abstractions. So my question is - is it right, or wrong, and if wrong how it should be done in appropriate way?
Bundles are components in symfony2 that provides a functionality to your app. The frontend and backend approach has changed in symfony2, the bundles are used instead.
For example, you can create a BookBundle, and put all the functionality regarding to books in that bundle, adding, updating etc. And by configuring the routes, you can redirect all the requests about the book to that bundle.
The main point is, the frontend and the backend about the books resides in same bundle, and only in that bundle(with controllers and entities and repositories and views etc.).
This is the intended usage in symfony2.
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.
We're planning a new intranet for our organization. Some part is like a CMS, and there are some custom-made applications.
The Symfony2 CMF distribution looks fine for building the CMS part of the intranet, but other parts like Doctrine, "normal" SQL databases, etc, looks better for the custom-made applications for the intranet.
Because I need common authorization and authentication system for this intranet (against an Active Directory), I supose that I'll get better results building all in only on app. So, can I mix a CMF application with a normal application, and both use the same database (an Oracle DB)?
Yes you can easily mix the CMF with other Bundles. For example the routing allows using both routes from the CMF as well as "static" routes defined in yml files. Also you can easily also add the ORM next to PHPCR ODM. If you use Doctrine DBAL for storage in PHPCR, you can even reuse the same connection configuration with the ORM etc.
In brief yes it is, and I do this in my own Symfony2 project. I combine both SF-SE and SF-CMF bundles.
In fact, with Symfony2 it's very simple (this is just a matter of choosing the most suitable Bundles; SF is a very decoupled framework, which is why I don't plan to migrate to any other solution for the moment), but I'd like to share some of my experience with doing that. Actually the one most important question to think through to make a decision about how to combine both "worlds" is this:
Composer.
After some inquries I found out that since Symfony CMF is (in a way) based on Symfony SE, and not vice versa, it's better to start with the latter, as it contains the most core features (though I did it also in the opposite way, rather not recommended). So just take a SF-SE's composer.json, take a look at bundles from there you need, and then take a look at differences within SF-CMF's composer.json. You should end up with the most suitable set of bundles.
The basic features from these bundles to look-up for are:
MODEL - Doctrine ORM, PHPCR-ODM, or both - if still not sure, don't hesitate to ask a comment, I'll share here my experience furthere.
ROUTING - the primary question here is how flexible routing do you actually need? If not sure, I'd go with standard SF Router, and then possibly replace it e.g. when still on a dev stage.
OUT-OF-THE-BOX CMS FUNCTIONALITY - bundles such as CreateBundle, MenuBundle or MediaBundle may help you building surprisingly fast, but not quite flexible soltions. In general, I ended up without using most of them, and if using, then I mainly take some Interfaces I do implement in my own Bundles (to ensure future compatibility with possible other bundles to be potentially used).
Besides of these above, I created a number of Bridge Design Pattern and Provider Design Pattern solutions to make some bundles working together, to adjust their functionalities, or simply to decouple things.
In programming almost everything is possible. But think about restrictions delivered with CMF (routing for eg.).
Maybe you should consider Standard Symfony with Sonata? I think CMS pages it's only small part of your system and implementation it in standard symfony will take smallest part (and cost) of whole project.
I'm developing a SaaS where tenants are both real ones and admins (us). So "fornt-end" and "back-end" are the same. Anyway, according to many other questions bundles are a way to structure your project in reusable way.
I really don't think that our bundles are going to be reused, but i still need a way to split the project into bundles to quickly find files we want to work on. Application should:
CRUD for customers - tenants should be able to manage their
customers/partnerships
CRUD for customers tags and keywords (a way to categorize their customers)
CRUD for broadcast notifications sent by us (a messaging system)
CRUD for tenants - we should be able to manage our tenants
So, how can organize my bundles? Could be:
CoreBundle: only Doctrine2 models
ResourcesBundle: templates, js, css, images
SystemUserBundle: manage tenants and customers CRUD
MessagingBundle: message system
How this design can be improved?
According to the Symfony2 documentation:
In Symfony2, a bundle is like a plugin, except that all of the code in
your application will live inside a bundle. A bundle is nothing more
than a directory that houses everything related to a specific feature,
including PHP classes, configuration, and even stylesheets and
Javascript files (see The Bundle System).
Personally, following this description, I would set up the SystemUserBundle to contain the Doctrine2 model and templates/js/css/images that specifically relate to managing customers, rather than splitting them out into CoreBundle and ResourceBundle. However, splitting your app into SystemUserBundle and MessagingBundle sounds like a reasonable approach.
I like to think of it this way - does the bundle encapsulate some behaviour that I might need or want to plugin to a future Symfony project(s) I am involved in. Customer Management, for example, is something that might apply to any app and be re-used across projects (indeed, this is why the extensible FOSUserBundle exists).
I don't think the Symfony2 docs go into sufficient detail on bundles (yet!) but in case you haven't found all the relevant sections these are the ones I'm aware of:
Symfony 2 Page creation
Symfony 2 The Bundle System
Symfony 2 Bundles best practices
I am new to Symfony, please don't scold me about this question.
I read in a Symfony 1.4 book that there is a functionality of adding backends to your applications via doctrine:generate-admin or generate:app backend, implementing CRUD operations.
Now I wonder, is there anything similiar with Symfony2.0?
Basically I have an user management and a database in the background that I would love to have available for my Admin Users, but do I have to code it myself (i.e. securing the are /admin, creating templates, classes, methods etc. that fulfill this tasks) or can it be done more easy by using some kind of an already existing backend functionality?
Thanks!
EDIT: Also read there's a plugin called "Apostophe" - but isn't there anything included with SF2 or are there any preconfigured SF2 Versions that already come with Backend solutions?
There's the SonataAdminBundle (and possibly a few more I haven't seen) that helps provide an admin system, however this area is still being worked on heavily by the Symfony2 community.
Lukas has put together a blog article on the current state of development of a Symfony2 CMF, with some rough timescales - State of the Symfony2 CMF
Hope this helps!
Also there is another bundle for managing the admin. You can take a look here http://knpbundles.com/cedriclombardot/AdmingeneratorGeneratorBundle
For "admin generation", Symfony2 is not yet with the code generation on that aspect. The base is VERY STRONG. Remember Symfony2 is still at 2.0 stage. (Not 2.1++ like symfony1).
If you want cut and paste code. Symfony2 is not exactly for that.
DISCLAIMER
I am more specialized in frontend than backend, but I got around stuff. But Thanks to Symfony2. I can be on both sides. So I speak from this context.
CAVEATS
What I call "good stuff".
Only using ONE {{ form_widget(form) }} that Symfony form documentation recommends ... and not explictly cut and pasting from the Twig tutorial that is /meant/ to show how to do theme... not to implement like it is shown.
Thinnest controller methods possible
... out of scope of this post.
SO
My best advice is serious RTFM, a few times, with Symfony books. It is scary, but I am working with it since three months and re-reading a lot. Everytime I get excited with gems.
ANSWER IN QUESTION
My current choice of bundles is:
FR3DLdapBundle, with FOSUserBundle
MopaBootstrapBundle along with all code generated with HTML/CSS structure Twitter Bootstrap gives. (if you haven't heard of it, yet, where were you?)
AsseticBundle with proper {%- javascript %} inclusion
And the rest is contextual.
My READ and RE-Read list
A hidden gem and very helpful blog posts were for me from:
Problematic's blog post series "On a diet"
Matthias Noback
Liip Symfony2 tagged blog posts, but mostly the Table Inheritance topic
and CraftItOnline
For the sake of completeness there is a native way to generate CRUDs:
php app/console doctrine:generate:crud
This command will ask to you some information, like the entity, if you want a write action, the configuration format or the base route prefix.
In my opinion this is the fastest and light way to quickly generate a controller to create, read, update or delete your entities, so it is good on simple projects or to code a basic CRUD inside a little Bundle.
Official documentation: http://symfony.com/doc/master/bundles/SensioGeneratorBundle/commands/generate_doctrine_crud.html
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.