官术网_书友最值得收藏!

Business logic versus presentation logic

We start this chapter by discussing an important architectural choice that modern applications make: how to turn data into presentation.

So, what would be the best way to get our data and functionality marked up? Do we simply wrap each piece of data in HTML and return the whole thing as a giant string, as shown in the following example?

return '<p class="wrapper">' . $data . '</p>';

No, we don't. Like all other well-designed applications, Drupal separates its business logic from its presentation logic. It's true, previous versions of Drupal did use this kind of approach, especially when it came to theme functions, but even so, they were easily overridable. So, constructs like these were not found smack in the middle of business logic but were encapsulated in a special theming function that was called by the client code. So, the separation of business logic from presentation logic was clearly there.

Traditionally, the primary motivations for this separation of concerns were as follows:

  • To make the code easier to maintain
  • To make it possible to easily swap out one layer's implementation without having to rewrite the other layers

As we will see, Drupal takes the "swapability" aspect quite far. You may think that the theme you select on the Appearance page is responsible for applying the HTML and CSS for the website. This is true, but only to some extent. There are thousands of contributed modules on Drupal.org. Also, you can write a bunch of your own. Should the theme be responsible for marking up all of those modules' data? Obviously not.

Since a module is most intimately familiar with its own data and functionality, it is its own responsibility to provide the default theme implementation—that initial look and feel that is independent of design and that should display the data correctly regardless of the theme. However, as long as the module uses the theme system properly, a theme will be able to override any HTML and/or CSS by swapping the module's implementation with its own.

In other words, after data is retrieved and manipulated inside the module (the business logic), it will need to provide the default theme implementation to wrap it inside its markup. Sometimes, a particular theme will need to override this implementation in order for it to achieve a specific design goal. If the theme provides its own implementation, Drupal will use that theme implementation instead of the module's default implementation. This is usually called overriding. Otherwise, the default fallback will still be there. The theme also provides the option of applying styling via CSS only and leaving the markup provided by the module intact.

主站蜘蛛池模板: 阿瓦提县| 云林县| 金沙县| 洛阳市| 裕民县| 玉屏| 潞城市| 靖江市| 孝昌县| 天全县| 华宁县| 大厂| 石泉县| 赫章县| 鱼台县| 麻江县| 昭觉县| 玛多县| 呼伦贝尔市| 清河县| 房山区| 柞水县| 衡阳县| 泸州市| 凤庆县| 志丹县| 周口市| 平乐县| 怀宁县| 桑植县| 邳州市| 靖州| 奉节县| 阳曲县| 确山县| 徐水县| 青龙| 临沂市| 浠水县| 遵义县| 河曲县|