Archive for the 'Chain of Responsibility' Category

Sandlight CMS IV: Dynamic Responsive Web PHPages

responsiveAt this point in the Sandlight CMS development process, two design patterns have been employed: 1) Chain of Responsibility as a device checker, and 2) Abstract Factory for making different parts for different devices. As usual, I’ve been posting the results so far on the Sandlight Productions, LLC website. The site itself is the example used in this series. This post is Part IV of the Sandlight CMS series, and if you have not been following the series you can review what has been done so far beginning with Part I.

At this stage, the project is ready to use the Abstract Factory to produce the needed parts and put them together into a page. However, before going ahead and have the factory build the parts I’d like to take an intermediate step and just build a dynamic responsive Web page.

The Dynamic Responsive Web PHPage

The easiest way to proceed is to begin with an HTML5 page, encapsulate the page into a PHP object (class) and add methods. The reason for this step is that the Web site, in addition to being responsive, needs to be dynamic. This means that it needs a way for the administrator to add changes, and in order for this to transpire, the dynamic portion of the page has to include variables in the place of static text, graphics and/or video. Figure 1 shows the general layout envisioned for the page:

Figure 1: Dynamic Responsive Web Page

Figure 1: Dynamic Responsive Web Page

Everything about the page must be responsive, but some parts are static and some are dynamic. In the two-column outline in Figure 1, the entire left column is static yet it must be responsive to different devices. In Parts I to III of this series, the pages have been responsive. The next step in making them both responsive and dynamic is to create parts of the page that will be dynamic since they are already set up to be responsive. Before continuing, click the Play button to see the progress so far and the Download button for all of the source code and accompanying files:
PlayDownload

Using PHP alone, creating a dynamic page is simple. Just place PHP variables where content goes. This is true for both the pages formatted by CSS3 and jQuery. Importantly, though, all of the Web pages should be encapsulated into PHP classes, using heredoc string variables as has been shown in previous installment of this series.

QR Code: The New Responsive Component

Quick Response Code (QR) is a new necessity for Web sites doing business on the Web and for just about every other kind of site that wants to increase its exposure. Basically, using a QR Code reader in a mobile device (phone or tablet) automatically brings up the link coded in the QR image (a square with some squiggly block images.) That beats trying to to thumb in a URL on a tiny phone keyboard. The following two can be downloaded free (at the time of this writing.):

sandlightqrcodeI’m pretty certain that other smart phones have QR readers; so if you have something other than an iOS or Android operating system on your mobile device, an Internet search for “QR Scanner” will probably be able to locate one for you.

sandlightOnce you have a QR scanner, you need a coded image, such as the one to your right. Go ahead and scan it to see what happens. It should take you to the Sandlight Productions, LLC home page build on this CMS (updated.) On it you will find several more QR codes for links to sites related to Sandlight. You can get the coded images online at different sites. One site allows you to include your logo and choice of colors is QRCode Monkey. The QR code image in green to your left with the Sandlight logo in the middle does exactly the same thing as the black one. So, if you’d like your QR Code images to keep your graphic designer happy, consider the visual options beyond the default. Figure 2 shows a page being scanned with an iPhone (left) and the linked page in the iPhone (right).

Figure 2: Scanned QR URL uploaded in mobile phone.

Figure 2: Scanned QR URL uploaded in mobile phone.

Adding QR codes to your site (or your client’s site) is very easy, and you should definitely include it in your dynamic responsive CMS. Let’s now see how the dynamic responsive two-column page is created:
Continue reading ‘Sandlight CMS IV: Dynamic Responsive Web PHPages’

Sandlight CMS II : Mobile First!

mobileFirstI’m not a graphic designer, and so I depend on others for the graphic elements and arrangement of my Web pages. However, I strive to make a site that is clear, easy to understand and useful. My focus is on good user experience (UX) and information design—clear communication with the user. In order to have good UX, you need to know something about , and if you don’t, check out the RWD link. Further, if you are unfamiliar with the approaches to RWD, I’m sold on the Mobile First approach, but possibly for different reasons than designers. Let me explain.

In designing my own site, my focus is on content categories, ease of maintenance, which includes updates and changes, and device flexibility. So I have to keep all of those in mind. I want PHP to handle regular updates by using content from a MySql database (the Content Management of CMS), and I need it to work on different devices. By tackling mobile first, I have to create a diamond-tipped focus on exactly what I want the user to view because even with the new “Phablets,” I’m not dealing with a lot of screen real estate. Currently, my old working mobile phone has a CSS resolution of 320 x 480, and my Phablet is 414 x 736. That’s less that 100 units different. (By CSS resolution, I’m referring to what CSS reads as far as screen width is concerned. See this table.)

Choosing the Devices

In an another sniffer program using a Chain of Responsibility (CoR) design pattern and a PHP user agent ($_SERVER['HTTP_USER_AGENT']) posted on this blog, the sniffer detected the user agent and then found the handler responsible for that agent. Now that user agents have been replaced by CSS screen width (as determined by a JavaScript function) for determining the device, we can use the same CoR pattern making the necessary changes. However, instead of getting real pages, we can use stand-ins that only have the roughest page content. All of the content will be encapsulated into PHP classes using heredoc strings. Near-future posts cover the mechanics of working out the MySql to provide dynamic content for the pages, along with other details necessary for the CMS. For now, though, the dummy pages will only contain enough material to demonstrate that each is appropriate for the selected device. Use the buttons below to see the current state of the CMS and download the files for this portion:
PlayDownload

Note that all devices can now access the Flag Counter. Where is your country on the Flag Counter? (See the note about the Flag Counter at the end of this post.)

Back to the Chain of Responsibility Pattern (CoR)

The CoR pattern is handy because it’s easy to update and change. For example, suppose that having three device categories (e.g., phone, tablets and desktops) proves to be inadequate and you want to add two more; one for laptops and another for phablets. It’s a simple matter to add to the chain and add device classes to handle the new devices. Figure 1 shows the first design pattern to be used in the CMS:

Figure 1: Chain of Responsibility Implementation

Figure 1: Chain of Responsibility Implementation

In Part I of this series, you can see how the device width and height is determined using a JavaScript closure (object) to pass the information to HTML and on to PHP. Since we only need to find the width, the JavaScript code has been slightly altered and placed in a separate file (deviceCatcher.js) in case it needs to be reused.

?View Code JAVASCRIPT
//deviceCatcher.js
function getWide()
{
        var wide = screen.width;
        return function()
        {
                return wide;
        }
}
var w = getWide();
//Send data to PHP class, CoRClient.php       
var lambdaPass= function() {window.location.href = "CoRClient.php?hor=" + w();};

The HTML file simply calls the closure function which passes the values to PHP:

?View Code HTML

        
                Device Catcher
                
        
        
        

The HTML file is a trigger to get the ball rolling with the client class (CoRClient).

Starting the Chain

The client pulls the viewing device’s width from the superglobal, and passes it to a PHP variable. Given the variability in the width of device screens, I made the decision to work with three sizes to get started: 1) phone, 2) tablet, and 3) desktop. So, depending on the width, the request would be handled by one of those three device groups. I used the following cutoff sizes:

  1. Phone: >= 480
  2. Tablet: >=481 and < 900
  3. Desktop: >= 900

I used this table as a guide, but cutoff points can be anything you want.

Getting the width from the superglobal is easy enough using a static variable:

self::$wide=$_GET['hor'];

The, using the cutoffs, the program needs to generate three strings, phone, tablet, and desktop to send to the Request class that stores the appropriate string. The most obvious way is to use conditional statements (if or switch) to generate the correct string for Request. For example an imperative algorithm such as the following would do the trick:

if(self::$wide < = 480)
{
        return "phone";
}
elseif (self::$wide >= 900)
{
        return "desktop";
}
else
{
        return "tablet";
}

However, a functional program would be more compact, and like the JavaScript closure used in Part I, it would be an “object.” Transformed into a functional closure, the operation would look like the following:

$beta = self::$wide >= 900 ? 'desktop' : 'tablet';
$lambda = function($x) use ($beta) {
        $alpha =  $x < = 480 ? 'phone' : $beta;
        return $alpha;};

Using ternary operations ?: , $alpha and $beta both have function-like qualities. for example, $beta could have been written as a function beta() as shown in Figure 2:

Figure 2: "Functional" variables

Figure 2: “Functional” variables

As you can see in Figure 2, $beta provides the same functionality as beta(), and $beta can be used as a reference in the $lambda function along with $alpha in a PHP closure. (For some reason, when $beta is assigned an anonymous function, I was unable to get it to be added as a closure in the $lambda anonymous function.)
Continue reading ‘Sandlight CMS II : Mobile First!’

Chain of Responsibility Mobile Sniffer

snifferUpdate!

This pattern was used on the updated Sandlight Productions site. Check it out. (Now back to our regularly scheduled program.)

Sniffing along the Chain

While working on Learning PHP Design Patterns I build a sniffer to go with a CMS app that used an Observer pattern. At the time, I was thinking that I should really add a Chain of Responsibility (CoR) that could then send out content via the Observer pattern. In any event, I decided to go ahead with the project and post it on this blog.

To get started, take a look at the initial article on this blog explaining the Chain of Responsibility design pattern in PHP. The code in this application re-uses the bulk of the original one posted—remember that re-use is one of reasons to employ design patterns and this blog should certainly set examples where possible.

A Mobile Sniffer and a Chain of Choices

One thing we know for sure in the world of mobile devices is that more are sure to come. Once we make a nice big Web site that the client absolutely loves, along comes another mobile device.

“Ah, Joyce, could you add something so that the Bizarro 5000 can be detected?”

So don’t act like you didn’t know this was coming. That’s why the Chain of Responsibility is called into service. So we’ll add a class for the Bizarro 500 (Biz5000), link it to an appropriate Web page or make a new one, re-jigger the Client, and Bob’s your Uncle! Done and done.

Test the CoR Sniffer on your different devices to see the different results. If you have a device that you cannot connect, send in a comment and we’ll work out how to add your device to those sniffed out. Also, download the files for this post:

PlayDownload

To get started, create a Handler abstract class. This will provide the abstract methods that give us lots of flexibility and loosely couple the classes. (It’s not much different than the original one created on this blog.)

< ?php
        abstract class Handler
        {
                protected $site;
                abstract public function handleRequest($request); 
                abstract public function setSuccessor($nextService);                
        }
?>

The $site variable is one that will be used to instantiate one of three Web page builders. The two mobile sites (phone and tablet) will use jQuery Mobile, and the desktop site will be treated as a default site and uses no special code—just plain CSS and HTML. All of the sites are generated inside a PHP file using HEREDOC formatting.

Keeping in mind the the Chain of Responsibility design pattern is super simple to build, all we need are some concrete handlers and a Client. The Client participant in this pattern is hard-working, and a helper class, Request, has been added to help shovel requests to the concrete handlers. For this example, only four concrete handler classes have been created:

  1. Iphone
  2. Android
  3. Ipad
  4. Desktop

You may well ask, “What about Kindle Fire, Surface, and Blackberry?” And the answer is, “Add them yourself.” Keep in mind that design patterns are flexible, and it’s easy to add and change the parts.
Continue reading ‘Chain of Responsibility Mobile Sniffer’

PHP Chain of Responsibility : Making a Selection

The Chain of Responsibility (CoR) design pattern is used when you need a request handled by the most appropriate object for the request. You don’t need to worry about which object handles the request or even if they’ll handle it the same all the time. For example, suppose you have a constantly changing marketplace and the specs of your request change as well. Rather than building an application that links a specific request to a specific request handler the CoR pattern decouples the two so that when a request is sent, all you know is that the most appropriate object will handle it. Our department buys USB drives in bulk from China. In the request for the drives I put in a set of criteria and send the request to my Chinese buyer. He is instructed to get the lowest price for the drives as long as they meet the specs in the required bulk. Now I don’t know which manufacturer will win the contract (which object will handle the request), but since I trust my agent in China, I am confident he’ll get the best price even though the price will vary depending on everything from the dollar’s exchange rate with China to the availability of USB drives. Because so many variables change, I need the flexibility that changes with both the request and the request handler. That’s something like the way the CoR design pattern works—it takes a request and finds the most appropriate way to handle it.

Play the application to see what happens (not much) and download the code using the following buttons:

Chain of Responsibility Overview

Because looking at a Class Diagram is useful for seeing the larger context of the design pattern, we’ll look at it first and then go about describing its features.

Figure 1: Chain of Responsibility Class Diagram

This looks fairly simple, and at the basic level it really is. Like some of the other design patterns, the Client is part of the pattern, and so it’s integral. At the center of the pattern is the Handler interface. For the time being, think of the interface as an abstract class because that is what is used in the initial example. The abstract class includes a function for setting successors in a chain and another to handle a request. Finally, the ConcreteHandler classes represent the specific and different classes that handle requests. Generally speaking, an application would include several ConcreteHandler classes, and each is set up in a chain to deal with requests where appropriate.
Continue reading ‘PHP Chain of Responsibility : Making a Selection’