Patterns of Enterprise Application Architecture - Day 7

We continue in our chapter of Web Presentation
Today we will discuss View Patterns and Input Controller patterns 😉

A. View Patterns

On the view side there are three patterns to think about: Transform View (361), Template View (350), and Two Step View (365). These give rise to essentially two choices: whether to use Transform View (361) or Template View (350), and whether either of them uses one stage or a Two Step View (365). The basic
patterns for Transform View (361) and Template View (350) are single stage. Two Step View (365) is a variation you can apply to either.

keep calm , i know there is just words and no images, let's go 😄

A.1. Template View

Here we do not need any images because the explanation is very clear, look what the book says :

Template View allows you write the presentation in the structure of the page and embed markers into the page to indicate where dynamic content needs to go. Quite a few popular platforms are based on this pattern, many of which are the server pages technologies (ASP, JSP, PHP) that allow you to put a full programming language into the page. This clearly provides a
lot of power and flexibility; sadly, it also leads to very messy code that’s difficult to maintain. As a result if you use server page technology you must be very disciplined to keep programming logic out of the page structure, often by using a helper object.

A.2. Transform View

Again like Template View the words in the books are enough :

The Transform View uses a transform style of program. The usual example is XSLT(Extensible Stylesheet Language Transformations). This can be very effective if you’re working with domain data that’s in XML format or can easily be converted to it. An input controller picks the appropriate XSLT stylesheet and applies it to XML gleaned from the model.

• ⁉️ Single Stage

The basic patterns for Transform View and Template View are single stage

A.3. Two Stage View

A two-stage view (Figure 4.3) breaks this process into two stages, producing a logical screen from the domain data and then rendering it in HTML. There’s one first-stage view for each screen but only one second-stage view for the whole application. The advantage of the Two Step View (365) is that it puts the decision of what HTML to use in a single place. This makes global changes to the HTML easy since there’s only one object to alter in order to alter every screen on the site. Of course, you only get that advantage if your logical presentation stays the same, so it works best with sites where different screens use the same basic layout. Highly design intensive sites won’t be able to come up with a good logical screen structure.

B. Input Controller Patterns

B.1 Page Controller

In the simplest case this Page
Controller (333) can be a server page itself, combining the roles of view and input controller. In many implementations it makes things easier to split the input controller into a separate object. The input controller can then create appropriate models to do the processing and instantiate a view to return the result. Often you’ll find that there isn’t quite a one-to-one relationship between
Page Controllers (333) and views. A more precise thought is that you have a Page Controller (333) for each action, where an action is a button or link. Most of the time the actions correspond to pages, but occasionally they don’t.

B.2 Front Controller

Front Controller (344) goes further in this separation by having only one object handling all requests. This single handler interprets the URL to figure out what kind of request it’s dealing with and creates a separate object to process it. In this way you can centralize all HTTP handling within a single object, avoiding the need to reconfigure the Web server whenever you change the action structure of the site

End of that chapter ❤️