Integrating Utilities, Views, and Messages PHP Help

You’re finally ready to put all of this together. Let’s revisit src and the less refined messaging that started the entire journey that led to .

coding

coding

This code is no longer needed, so you can remove it, now and forever. Time to get a lot more elegant.

Calling Repeated Code from a View Script

First, add in the require_once for your new view-related function script:

coding

coding

Next, add a call to the display-messages function in your HTML

coding

coding

There’s a bit of a problem here. display_messages takes two parameters: a success message and an error message. “Therefore you need some way to pass in an empty message, and then display_messages needs to handle an empty message on the receiving end

By whatever means the issue with errors is resolved, this structure should become a standard part of all your HTML. Anytime you’re displaying HTML, you want to allow for message handling. That means you’re back to repeat code: every single view-related script has started out with the same basic HTML (although occasionally you’ve needed to insert some JavaScript, as

coding

coding

Now, you have your body tag, the same header-more repeated code-and then a page title. Also, you have messages to display. Here’s another chance to take code that you’ve been typing into your scripts, over and over, pull that repeated code out, and then drop it into yet more utility functions. Your View script is about to get a lot bigger and a lot more useful

Flexible Functions Are Better Functions

You now have a list of interrelated things with which you must manage, most of which involve updates to

• display_messages should handle empty or non-existent messages for the success and the error message. If either message isn’t set, the <div> related to that message shouldn’t be output.

• You need a new function-call it display _header-that handles outputting the head section of each page’s HTML. This function should take in JavaScript that can be added to the document’s head, but should also handle the case in which there’s no extra JavaScript needed

• You need another new function-call this one display _title-that prints out the page title; the page’s subtitle, which is passed in by each script; and any message, which also should be passed in by the calling script

None of these functions are particularly difficult, so it’s time to get back to work

USE DEFAULT ARGUMENT VALUES IN DISPLAY MESSAGES

Returning to display _messages needs to be able to accept a non-value for a message. Recall that in PHP, this is handled by the special keyword NULL, which means “non-value.”

Now, because NULL is a non-value, you can’t compare it to a value. So, this code doesn’t make sense in PHP:

if ($value == NULL) // do something

What you need to use is another PHP helper, is_null. You pass a value to is_null, and PHP informs you about what you have

Now, it’s possible to make an update to display_messages. If a message passed in is NULL. there’s no need to call the individual display_message for that type of message

coding

coding

There’s just one thing missing: what if a script-like have a value to pass in for $error _msgor $success _msg?In these cases, you Want display_ messages to have a value. This is a value that’s used if nothing else is passed in.

You can assign the default value for function’s argument like this:

function do_something(this_value = “default value”) {
// do something with this_value

Thus, for display_messages, the default values should be NULL (no value):

coding

coding

Your display messages function” is finally ready for use by the other functions you need to add to

OUTPUT A STANDARD HEADER WITH HEREDOC

Next, you need to deal with the standard HTML output for a page in your app. That’s basically the opening <HTML>,the <title>, the <head>, and any page-specific JavaScript that needs to be added. Of course, with vi,?w.pilp in place, your knowledge of functions, default arguments, and everything else you’ve already done, this step should be a piece of cake.

You can create a new function, and because it’s possible that some scripts need to pass in JavaScript to add to the <head> section, but others might not. using a default value for a function argument is again the way to go:

function display_head($page_title $embedded java script = NULL)This function, by the way, sets a default value for the $page_title, too. That’s not completely necessary, but again, it’s a bit of extra protection. This way, if someone calling this function forgets to send in the title, the HTML output can be constructed regardless

The body of this function is just some echo work and a conditional for the potential JavaScript

coding

coding

Notice that the link line uses single quotes around the HTML. This is so you can use double-quotes for the href, rel, and type attributes. Unfortunately, you’re going to have to either use multiple quote styles like this or escape a lot of your quotes with and  Neither solution is particularly pretty, so pick your own poison

Of course, programmers aren’t used to limitations like this, and you should immediately be thinking, “Wait a second. I’m a programmer. Why am I stuck with two bad solutions?” Well, you’re not. What you need is a way to deal with multiline strings, and PHP doesn’t disappoint. In fact, multiline strings are such a common issue in PHP that it gives you a couple of ways to deal with them .

The most common solution is to use something called tieredoc. The heredoc method gives you a way to mark the beginning and the end of a piece of text. Everything between those beginning and end markers is treated as text, without you needing to surround things in quotation marks.

You start a string of here doc by inserting three less-than signs «). You then add a sequence that you’ll use to mark the end of the string:

$some_text =, <<<EOD

In this example, you’re saying, “I’m starting some text and the text will end when you run across EOD.”

Having done this, you can put as much text as you want in the string. You can use multiple lines, single quotes, double quotes, and even the {$var_name} syntax. It’s all fair game

coding

coding

Put all of this together, and you :an clean up the look of display_head quite a bit:

coding

coding

You probably noticed that in this version of display , head, there was no need to assign the string created by using here doc to a variable. You can directly output the multiline string and save a step. The result is actually a hodgepodge of echo, heredoc, conditional logic, and potentially some JavaScript. Nonetheless, it’s becoming increasingly easy to read, and that’s a good thing

UPDATE YOUR SCRIPT(S) TO USE DISPLAY_HEAD

Now, you can head back to show_use’s if you like) and remove lots of HTML. Replace the HTML for the head of your document with a call to display_head. While you’re at it, you might want to use a little more here doc in the process, particularly in snow which sends some JavaScript to be embedded:

coding

coding

This code uses here doc, so creating a string of JavaScript to pass to display_head doesn’t involve lots of escaping single or double quotes. In fact. you’ll find that here doc is almost as handy to have around as sprint f (page 298), and you’ll use both liberally for outputting HTML or other long stretches of text.

There’s still the issue of displaying messages, but before you get to that, tryout your changes to G. You should see something like Figure 11-16.

php and MySQL

php and MySQL

Standardizing and Consolidating Messaging in the View

All that’s left is messaging, You have a display_messages function, but it’s not integrated into the HTML that’s typically around those messages. Just as display_head” output HTML with some potential embedded JavaScript, the first part of your page should output some standard HTML, the page title (again), and potentially success
and error messages. The final output should look a bit like this:

coding

coding

coding

coding

Things are looking good: display_head and display _ti are both great, and you already have calls to display_head in place. However, before you go adding in a call to display_title in all your scripts, take a moment to think about what you’ve done

Building a Function to Call Two Functions

• Remember, the idea here was to create another function, display _title, to handle outputting the starting portion of every HTML page’s body. But now that you have that function, there are a few things to think about:

coding

coding

coding

coding

Just Pass That Information Along

What’s left? Removing calls to display_head; avoiding another call to display_ ti and finally, one call to rule them all. In fact. take a look at the new, improved This script is shorter and a lot clearer. Even with the bit of indentation clutter that heredoc introduces, this is a pretty sleek script

coding

coding

coding

coding

At this point, take it out for a spin. Verify that error messages work. Confirm that success messages work. Change your other scripts to also use page_start. You can even add more functions to Maybe you want a page_end that outputs the closing <div>, the footer, and some contact text. You could add a sidebar function.

With this modular approach, you can do anything you want. Well, except for controlling just who gets to delete users. That’s a problem for the next chapter.

Two Functions Are Better Than One …Kinda

One of the things you’ve seen over and over is this idea of moving smaller and smaller bits of code into their own functions. This means that you have a little bit of HTML in a function in You have (i)
doing database connection, and even though it doesn’t define a custom function, it’s basically called like a function through require_once. The same has been true a number of times: take small pieces of behavior or functionality and put them into small, easy-to-call functions.

It might be easy to think that the goal is lots of individual function calls. That’s partially true. What is true is that you want lots of building blocks that you can assemble into bigger useful pieces. But, when it comes to using those functions, do you really want to-make 20 or 30 individual calls? Probably not Just think about it: is it easier to remember to call display_page, and then have to look up the arguments to pass, or is it easier to remember to call display_head, and then display_messages, and then display_content, and then …what was that next one again? Of course, it’s easier to make the one function call

Just think about it: is it easier to remember to call display_page, and then have to look up the arguments to pass, or is it easier to remember to call display_head, and then display_messages, and then display_content, and then …what was that next one again? Of course, it’s easier to make the one function call

That’s why you want to move toward a hybrid of small functions with groupings or higher-level functions that assemble those small functions in useful ways. Your scripts should make simple calls rather than lots of calls. And then, those simple calls can do whatever is needed, even if that means calling lots of smaller functions behind the scenes.

The result should be simpler, easier-to-read code. As  you’ll also get a nice set of functions that you can combine in a variety of useful ways

Posted on January 14, 2016 in Handling Images and Complexity

Share the Story

Back to Top