Call Us Today! (443) 500-7624
The world is changing and with that, the world of technology is changing as well, and everyone who is part of society must adhere to new sets of rules and standards that come with a chance to develop a successful society.
In today’s article we are going to continue talking about Drupal and focus again on coding standards. Formatting is part of Drupal’s coding standards, and it coves things such as whitespace, aspects which influence the format and appearance of your code and the way that the code should be structured.
Indentation in Drupal is very specific, developers should use 2 spaces of indentation, although there is much debate in the programming world, about indentation. The way to end your code on a file would be to leave one extra blank line at the end of the file, this file ending structure is known as the Unix file ending.
In Drupal, operators should always have one space around them, specifically the ones that are enclosed under parenthesis. For example,
if ($a == 'system' || $b == 'system') { return $a == 'system' ? -1 :<span style="font-family:sans-serif,arial,verdana,trebuchet ms"> </span><span style="font-family:sans-serif,arial,verdana,trebuchet ms">1;</span> }
Declaring and calling a function also follows coding standards, which describes that the argument list should come before putting a space. Before the operating curly brackets, should also have space before it. Parameters may be part of a function, if this is the case, then, they should be separated by a comma, followed by a space.
In Drupal, there are reserved words known as constants, which follow coding standards as well. Constant must always be capitalized in Drupal, some of them are: TRUE, FALSE, and NULL and as you can see they are capitalized. The known control structure items are: if, else, elseif, case, switch, for each, while, and do.
According to Drupal coding standards, there should be after the control structure term, and another space, before the opening curly brackets. Like functions, the closing brackets are on their own line and the statement inside one of the curly brackets is indented two spaces. A Drupal website development project must have standardized documentation, as part of its development, to understand Drupal’s code better.
When developers want to track what their code does, what variable it uses, what it returns, what to expect from the code, and what it returns, then he/she can always seek to well document their work. A developer’s code must be maintainable, by everyone and to ensure this take place, standardized documentation, must be used.
Documentation can clear a lot of misunderstandings and confusions, because a description of what parts of the code are doing, such as a function or large blocks of code, can be given during documentation, in the form of comments. Documentation can be written to give developers who read someone else’s code an overview of what a file contains, or what a piece of code is doing.
The Doc block is a block of information found at the top of a PHP file, or before each function, class definition or method. File doc block is also a block of information, which appears at the top of every PHP file, it is placed after a blank line and before another blank line. Tags can also be used in Drupal 8 documentation, they expected to go on a certain order, and indicate what a documentation in Drupal is all about.
\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