- Drupal 9 Module Development
- Daniel Sipos Antonio De Marco
- 445字
- 2021-06-11 18:36:05
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.
- 微商掘金:決勝微商的7個關(guān)鍵要素
- Photoshop CC淘寶美工實用教程
- 社群營銷
- 移動互聯(lián)下的超市升級
- 淘寶網(wǎng)店頁面設(shè)計、布局、配色、裝修一本就夠(最新實戰(zhàn)版)
- 傳統(tǒng)企業(yè)電商之道
- 互聯(lián)網(wǎng)營銷:理念的顛覆與蛻變
- 社群經(jīng)濟+社區(qū)O2O:重構(gòu)商業(yè)模式與營銷實戰(zhàn)
- 超級網(wǎng)紅:如何打造個人IP
- 互聯(lián)網(wǎng)+縣域:縣域電商那些事兒
- 直播電商2.0
- 個人信息保護問題研究:基于跨境電子商務(wù)
- 被看見的力量
- 移動互聯(lián)網(wǎng)商業(yè)模式創(chuàng)新與變革
- SEO網(wǎng)絡(luò)贏利的秘密:我是怎樣通過網(wǎng)絡(luò)掙到100萬的