Call Us Today! (443) 500-7624
It is no doubt that a world without principles and standards, would be a very scary place, because people wouldn’t be expected to perform to a level that is acceptable by others, when they do their jobs.
Imagine for example, if you wait for a red light to turn green, and you are in a country where they don’t take traffic light too seriously. You could bear to wait there for two or maybe even three minutes, but if you wait for more than thirty minutes, then you will notice that there is something wrong with the picture. So what do you do at that point, do you break the law, or do you wait for a light, that you know will not change, before you go?
In today’s article we are going to continue our conversation about Drupal on coding standards, and how you can improve your level of programming, if you learn to adhere to standards set by the Drupal community. Object-oriented programming (OOP) has become a large part of Drupal 8, which has introduced a lot of coding standards for the Drupal developer.
When developers want to organize their code to be more efficient, then they can choose to write their code in OOP, to use the best features that PHP has to offer today. Procedural programming does not give developers the ability to reuse their code, in the form of objects, which can be created or instantiated and contain properties that hold data, and methods that execute function.
Drupal only allow for one class per file, when declaring classes in OOP, the file name should be the same as the name of the class. In Drupal 8 there is a new feature known as PSR4 autoloader, which allow classes to be loaded on demand and automatically, but the naming convention should be followed.
A long list of required statements is not necessary due to autoloading, because classes are named based on the PSR-4 namespacing convention and are used on demand due to the autoloading system. The naming of the classes and how files and directories are arranged is what really matters, for the PSR-4 autoloader to work properly.
If you want your module to be autoloaded properly, you should follow this directory structure, according to drupilize.me. <modulename>/src/<namespace>. This file would contain a list of classes that are used, and inside the file the same coding standards should be follow, as far as spacing and indenting is concerned.
When naming classes, certain basics must be cover, for example, UpperCamel must be used when declaring a class or interface. lowerCamel can be used when declaring a method or a class property, the word “Drupal” or “class” should not be used to name classes. In Drupal, interfaces are used often, to keep the code flexible, because it allows developers to swap classes out for another, at some point in the future of their development if it’s necessary of course.
Developers use interfaces because they are flexible and allow them to implement different functionality, while sharing a common interface, this is known as polymorphism a OOP concept. Classes can be public, private or protected, to declare their visibility, which is a requirement.
Thank you for reading this article!!!
\Drupal\Component\Plugin\PluginManagerInterface,Implements all plugin managers, and this piece of code extends these three pieces of code, which are the basis for any new plugin manager.
\Drupal\Component\Plugin\Discovery\DiscoveryInterface, \Drupal\Component\Plugin\Factory\FactoryInterface and, \Drupal\Component\Plugin\Mapper\MapperInterface.The plugin.manager.* a piece of code is used to generate plugin manager services and from the service container, a copy of the plugin manager can be requested. Example:
$example_manager = \Drupal::service('plugin.manager.example');Once a developer has identified the plugin manager needed, to complete a task, then that developer has to start, by locating the name of the plugin manager service he/she needs. The controller will be the place where, a developer can inject their plugin manager services, and this is the Drupal way of doing things. The code below is a controller file, located under custom_module/src/Controller, it is very important that you get those names and file directory correct, for Drupal to recognize your controller and plugin.
<?php namespace Drupal\plugin_type_example\Controller; use Drupal\Core\Controller\ControllerBase; use Drupal\plugin_type_example\SandwichPluginManager; use Symfony\Component\DependencyInjection\ContainerInterface; /** * Controller for our example pages. */ class PluginTypeExampleController extends ControllerBase { /** * The sandwich plugin manager. * * We use this to get all of the sandwich plugins. * * @var \Drupal\plugin_type_example\SandwichPluginManager */ protected $sandwichManager; /** * Constructor. * * @param \Drupal\plugin_type_example\SandwichPluginManager $sandwich_manager * The sandwich plugin manager service. We're injecting this service so that * we can use it to access the sandwich plugins. */ public function __construct(SandwichPluginManager $sandwich_manager) { $this->sandwichManager = $sandwich_manager; } /** * {@inheritdoc} * * Override the parent method so that we can inject our sandwich plugin * manager service into the controller. * * For more about how dependency injection works read https://www.drupal.org/node/2133171 */ public static function create(ContainerInterface $container) { // Inject the plugin.manager.sandwich service that represents our plugin // manager as defined in the plugin_type_example.services.yml file. return new static($container->get('plugin.manager.sandwich')); } }All defined plugins have information that can aid our application development to move forward faster. All that information from defined plugins is available to developers when they can make calls to the getDefinitions method. Enabled modules, can be used to locate all plugin definitions of the type in question, through the discovery handler . When the discovery handler is not used to retrieve data, then the DefaultPluginManager is used to retrieve the data from the cache if the data is available there. A good example of is in the code below, watch how the definitions of a plugin can be obtained in the code.
// Get the list of all the sandwich plugins defined on the system from the // plugin manager. Note that at this point, what we have is *definitions* of // plugins, not the plugins themselves. $sandwich_plugin_definitions = $this->sandwichManager->getDefinitions(); // Let's output a list of the plugin definitions we now have. $items = array(); foreach ($sandwich_plugin_definitions as $sandwich_plugin_definition) { // Here we use various properties from the plugin definition. These values // are defined in the annotation at the top of the plugin class: see // \Drupal\plugin_type_example\Plugin\Sandwich\ExampleHamSandwich. $items[] = t("@id (calories: @calories, description: @description )", array( '@id' => $sandwich_plugin_definition['id'], '@calories' => $sandwich_plugin_definition['calories'], '@description' => $sandwich_plugin_definition['description'], )); } // Add our list to the render array. $build['plugin_definitions'] = array( '#theme' => 'item_list', '#title' => 'Sandwich plugin definitions', '#items' => $items, );When a list of plugin types is desired by a developer he/she may want to use the method above to accomplish this task. The unique ID of a plugin can be utilized in order to retrieve the definition of the plugin in question, calling the getDefinition($plugin_id) method. // If we want just a single plugin definition, we can use getDefinition(). // This requires us to know the ID of the plugin we want. This is set in the // annotation on the plugin class: see \Drupal\plugin_type_example\Plugin\Sandwich\ExampleHamSandwich. $ham_sandwich_plugin_definition = $this->sandwichManager->getDefinition('meatball_sandwich'); In order to instantiate and use an individual plugin object, the createInstance($plugin_id) method can be used. It is not good practice to instantiate a plugin object directly, instead, the plugin manager should be used to do so. Understanding how instances of a plugin are created requires that you see it in action, in the code below.
// To get an instance of a plugin, we call createInstance() on the plugin // manager, passing the ID of the plugin we want to load. Let's output a // list of the plugins by loading an instance of each plugin definition and // collecting the description from each. $items = array(); // The array of plugin definitions is keyed by plugin id, so we can just use // that to load our plugin instances. $sandwich_plugin_definitions = $this->sandwichManager->getDefinitions(); foreach ($sandwich_plugin_definitions as $plugin_id => $sandwich_plugin_definition) { // We now have a plugin instance. From here on it can be treated just as // any other object; have its properties examined, methods called, etc. $plugin = $this->sandwichManager->createInstance($plugin_id); $items[] = $plugin->description(); }All the code on this tutorial was taken from Drupalize.me. Thank you for reading this article!!!
Phone: (443) 500-7624
Email: admin@kinginfolife.com
Address: Baltimore, MD 21206
All Rights Reserved | KING INFO LIFE