Since you were quoting me, I will bite.

In the context it was written, business logic is the rules that govern how the data items are processed, display logic is how the user sees them. In the broad sense, yes, display logic is a part of business logic. But so is where you park and what entrance the employees are allowed to use.

In the context written, the distinction is made because it separates concerns. If Joe needs to fiddle a frobnotz and have the results displayed as a table, but Jane needs to fiddle the same frobnotz and have it displayed as a graph, why should the anything but the display side of things care. The frobnotz needs to be fiddled the same way. I would have my CGI connecting script (mod_perl handler, etc) fiddle the frobnotz and hand the results off to the right display module.

I better get back to work now, before my $workplace blocks access due to use of euphemisms.

In the context it was written, business logic is the rules that govern how the data items are processed, display logic is how the user sees them.

I see an area of application display that is not covered. What about conditional display? That is not _how_ the user seems them. It is what the user sees and a business rule made the choice.

In the context written, the distinction is made because it separates concerns.

I'm with you, but I would say it clarifies concerns. It makes it clear what sort of business logic is being executed, in this case the business rules guiding display.

I'm asserting that display logic ISA business LOGIC while you seem to be saying that business logic DISPATCHES-TO display logic.

I would say that display logic is a FILTER of what the business logic returns.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

The typical breakdown is that business logic defines what to display. The display logic decides how to display it.

Think of a stock quote app that can be accessed by desktop browsers and PDA/phones. In the browser you might present: price, high, low, volume, avg.volume, mkt.cap in figures, along with a day graphic and a 30-day graphic. On the PDA, you might only present the first three figures.

Your business logic doesn't need to know what kind of device the user has, it should just return all the information and allow the display logic to present it appropriately.

Likewise, if you decide to re-skin your site, the display logic will inevitably change, but the business logic will likely remain the same.

Model, view, controller (MVC) application development is one major way this is done. Your core business data is in the model. What to display when (as well as how to manipulate the model) is in the controller. How the data from the model is displayed is in the view.

My applications tend to have a class for each kind of business data with which I'll be dealing. An object of that class stores and retrieves the data. There is another object for the screen or web page. There is some code that retrieves data from the business object and updates the screen object. It's not a full-blown MVC framework, but my business logic doesn't need to be concerned with colors, placement, or sizes of items on the screen.

Are you familiar with the arguments for separating presentation and content? Broadly speaking the logic behind the presentation is called display logic, and the special rules about content (eg that a payment for the full amount of an invoice closes that invoice) are called business rules. This despite the fact that the company actually decides both sets of rules, and that it can be hard to clearly draw the line between the two.

The reason for drawing this distinction is exactly so that presentation and content stay separate. Which separation is good software engineering for a number of reasons, several of which become particularly obvious when multiple ways of presenting the same data exist. (eg A web application and a desktop application.) Or alternately if the same basic presentation is used to present many different kinds of content. (I have a reporting application that definitely fits the latter description.)

Let me toss in an off-the-wall example. Yesterday, I was at a restaurant when the credit-card machine and apparently most of the other computers briefly went down. They handled the crisis with aplomb. Thus, for a very brief interval, the ORDERS table in some database somewhere was not being updated ... yet orders were still being processed. In other words, “I still got my food and drink.”

For a brief amount of time, the computer representation of an order, or a juicy steak, or an excellent martini, simply did not exist. The staff smoothly switched to using an entirely paper-based representation of that workflow, and they had no need at all to be concerned with digitized representations of my martini. Nothing “suddenly disappeared off my plate” when the computers crashed, nor was I stuck waiting indefinitely for something to eat. When the computerized representation of a business-object known as an “order” ceased to exist, the staff employed an alternate, paper-based representation ... and no matter what representation had been used to reflect it, I was still able to place “an order.”

Some restaurants allow me to “place an order” with a fax-machine. There is no “display logic” in that case. Others allow me to place an order with my iPhone:   different display-logic. But the business rules established by the management of that restaurant apply generally to “orders”... no matter how they are placed, represented, or tracked.

Many people confuse a computer database with the Things that its multitudionous records represent, or model. They construct software that accurately reflects what the computer is doing, but not what the business is doing. As those two paths inevitably diverge, the software becomes fragile and brittle and is well on its way to the bit-bucket.

An “order,” or a steak or a martini, exists and is processed in a certain way, according to certain rules, in the real world, whether or not the computer is in any way involved with the process. Those rules will inevitably change from time to time. As the real-world changes (or, as the nature of the computer/display technology changes, e.g. “everybody gets a Personal Holo-Deck Device™ and starts to place orders with it”), we must be able to constrain the scope of those changes. Changes must not ripple uncontrollably throughout the source-code.

This is the familiar notion of “separation of concerns.” The display-layer is concerned with interpreting the bytes received from the client's display-device and for preparing an appropriate stream of bytes to send to it. Other layers of concern check to see if those inputs meet various syntactic and contextual requirements. Other layers of concern deal with interaction with back-end systems or the outside world. Still others deal with issues of business logic ... these being defined as “issues that are just as relevant when you're handling orders on-paper as they are when you're using the computer.” In my opinion, there are many layers above-and-beyond the familiar three: M, V, and C. Many of these layers are asynchronously or otherwise loosely-coupled with one another.

[% IF age < 10 %]
   Hello [% name %], does your mother know you're 
   using her AOL account?
[% ELSIF age < 18 %]
   Sorry, you're not old enough to enter 
   (and too dumb to lie about your age)
[% ELSE %]
   Welcome [% name %].
[% END %]
[download]

But I think Corion clarified this already.

Yes, and it has no (well, little) to do in the presentation layer.

Business logic concepts will always leak out to the presentation layer. Otherwise, how would it know what to display?

But the details, the implementation, of those concepts should stay in the model layer (if we talk MVC) or wherever the business logic is implemented.

In your example, it's suitable for the presentation layer to know that there are three levels of access, because it needs to display different things for the three cases.

But what are those hard coded age comparisons doing in a template??? That's the business logic which should be in the model layer. And those should be exposed as abstractions on a higher level than age comparisons.

That way other presentation modes can make use of these abstractions as well, so you don't repeat "age < 18" when you display this on a phone or in an email.

/J