Important
You are browsing the documentation for version 3.1 of OroCommerce, OroCRM and OroPlatform, which is no longer maintained. Read version 5.1 (the latest LTS version) of the Oro documentation to get up-to-date information.
See our Release Process documentation for more information on the currently supported and upcoming releases.
Differences to Common Symfony Applications¶
When you are familiar with building Symfony applications from scratch, you will recognize many well known building blocks when you start your first project using OroPlatform or OroCRM. However, there are some not so subtle differences you need to understand to efficiently develop your application.
This article will give you a short overview about the most important things OroPlatform differs from usual Symfony applications. Each section will link to other resources where you can learn more about a particular feature.
The Application Kernel¶
In Symfony applications, you usually register your own bundles as well as all the third-party
bundles from the vendor
directory in the famous AppKernel
class. This is not needed when
using OroPlatform. It ships with it own kernel that discovers bundles under the src
and
the vendor
directories automatically if the contain a bundles.yml
configuration file in
their Resources/config/oro
directory.
This file has to contain a list of bundle classes to initialize under the bundles
key. usually,
this will only be one class name:
1# src/Acme/DemoBundle/Resources/config/oro/bundles.yml
2bundles:
3 - Acme\DemoBundle\AcmeDemoBundle
Optionally, you can also specify a priority. The priority defines the order in which bundles will be loaded. If you omit the priority, its value will implicitly be 0:
1# src/Acme/DemoBundle/Resources/config/oro/bundles.yml
2bundles:
3 - { name: Acme\DemoBundle\AcmeDemoBundle, priority: 10 }
Caution
Other than what you would probably expect, a higher priority does not mean that a bundle is loaded before a bundle with a lower priority. Instead, lower prioritized bundles will be loaded first.
Tip
The default priority for all bundles is 0.
Routing Configuration¶
You can configure routes for your controller actions the same way that you are used with Symfony.
However, usually you would manually an import for your routing configuration in the main
routing.yml
file in your config
directory like this:
1# config/routing.yml
2default_controller:
3 resource: "@AcmeDemoBundle/Controller/DefaultController.php"
4 type: annotation
5
6acme_demo:
7 resource: "@AcmeDemoBundle/Resources/config/routing.yml"
8 prefix: /demo
With OroPlatform, you can still configure your routes the way you like. Though as long as you
create a main routing.yml
file located in the bundle’s Resources/config/oro
directory, you
do not have to register your routing config in the application config, but it will be discovered
automatically.
Access Control Lists¶
When it comes to Access Control Lists (ACLs), things are getting complicated. You need to deal with the ACL provider, object identities, ACEs, the mask builder, etc. OroPlatform makes things easier by providing an @Acl annotation that you can use to define an ACL and to protect a controller in a single step:
1// src/Acme/DemoBundle/Controller/BlogController.php
2namespace Acme\DemoBundle\Controller;
3
4use Oro\Bundle\SecurityBundle\Annotation\Acl;
5
6// ...
7
8/**
9 * @Acl(
10 * id="acme_demo.blog_post_view",
11 * type="entity",
12 * class="AcmeDemoBundle:BlogPost",
13 * permission="VIEW"
14 * )
15 */
16public function indexAction()
17{
18 // ...
19}
Furthermore, once an ACL has been defined, you can reuse it using the @AclAncestor annotation:
1// src/Acme/DemoBundle/Controller/BlogController.php
2namespace Acme\DemoBundle\Controller;
3
4use Oro\Bundle\SecurityBundle\Annotation\AclAncestor;
5
6// ...
7
8/**
9 * @AclAncestor("acme_demo.blog_post_view")
10 */
11public function postAction()
12{
13 // ...
14}
See also
Read more in the Security documentation.
Extension Management¶
Using composer, you can easily pull in third-party libraries and bundles that you need in your application. This does not change when using OroPlatform. But additionally to the common dependency management with Composer, you can also install a special type of package - an Oro Extension. An extension is a package that adds new features to the Platform. To achieve this, the OroDistributionBundle leverages Composer and Packagist. All extensions are feature on the Oro Marketplace. The cool thing is that you do not have to use the command-line to install extensions (of course, you can do this if you want to), but that a user with admin permissions can install them on their own in the UI.
See also
You can also add your own extension to the Oro Marketplace.