Talking Back to Your Users PHP Help

The addition of an alert confirmation box goes a long way on the front end of deletion It lets a user think twice about removing data and provides a mechanism to cancel the operation if she’s dissatisfied or concerned. Yet, that’s only half of the equation; not only do you need to confirm that deletion is indeed the intent, but then you need to verify that deletion was in fact accomplished.

Obviously, for you, the programmer, you’ve written code, you’ve run the code, and you might have even gone back to the database and done your own manual SELECT to ensure that results were deleted in ~. And, as expected, the user is gone from’

For a user that’s not enough Just as she will often want to confirm a deletion be C ire the deletion goes through she usually wants to now-beyond any shadow of doubt-that the deletion  gone rough This means that at the end of the process, she gets some sort of message that confirms what just transpired. Your flow should look something like this:

1. A user selects another user to delete by clicking the red “X” in show_users.php next to that user.
2. The user confirms that the deletion is intended.
3. delete_user.php handles the deletion of the selected user.
4. A message something like, “Yup, they’re gone, gone, gone.” is supplied to the user.
5. show_users.php displays the users list again, minus the deletion It’s step 4 here that’s new and requires a little thought.

redirect Has Some Limitations

Just looting at this flow, it seems like the natural place to handle confirmation-and display a post-deletion confirmation pop-up window-is within delete_user.php That’s the script that handles deletion, and it also comes before show_users.php lists all the users again.

For example, you might present a status message or display an alert pop-up window once deletion is complete But take a look at the last line from detete _user.php.

Redirection in PHP is done by using HTTP headers, which means that this line sends the browser a raw Location header. The browser gets the Location header and moves the HTTP response to the URL specified. No big deal, and it works great.

But (and this is a big but) header can only be called before PHP sends any output You can’t use echo or HTML blank lines or anything else in a file The browser can only get the headers and then it shifts the request So in reality, you can’t send anything before calling header and once you’ve called header you’re not supposed to send anything after that. Of course bugs are made when things that shouldn’t happen 00 happen and that’s why every call to a Location header is followed by that little exit statement to ensure that nothing else tries to execute.

In other words, a script like can do work on the database and other PHP objects, but it can’t do any output. It just deletes a user and then redirects output to a view script, like Therefore, you nave to figure out a way to interact with  and let that script handle letting the user know that a deletion’s gone down.

Model-View-Controller (Well. Sort Of …)

You’re starting to see an important web application pattern This pattern is called the MVC pattern which stands for model view controller In this pattern you have three categories of operation models views and controllers In a strict MVC pattern these three categories never overlap First there’s the Ci which interacts with the database The model represents or your app’s informetion.In your application, a script like  uses MySQL directly In a more formal MVC approach you’d have PHP objects like with methods such as delete or remove Soyou might write code like this:

User user_to_delete = User.find_by_ id($user_id);
user_to_delete.delete();

This example is a little beyond what you’re doing Still, you can see that the model part of MVC is what interacts with the database. For your code you don’t have a clear model but you’re doing plenty of database interaction.

Second, there’s the View this is what displays the information to the user. In your app, scripts like  are to some degree views They’re full of HTML and information The reason they’re only views to some degree is that they also share some controller behavior.

are the third category in an MVC architecture A controller directs traffic It uses the model to get information from the database or data store, and it passes that information along to view classes or scripts that display that information script is a lot like a controller Even though it directly accesses the database rather than using a model, it does something and then hands off control to a view.

In most PHP web applications you won’t have a strict MVC setup In fact it’s quite a lot of work to go full-on MVC with PHP You usually have a more hybrid approach, where controlleroriented scripts like hand off information to view-oriented scripts like also has aspects of a model, in that it talks directly to the database Additionally  has aspects of a controller and a model because it figures out what to show and it grabs information directly from the database.

So if you can’t do pure MVC in PHP why present this entire box about it Two good reasons First you’ll hear about MVC all the time and you’ll be a lot more popular at the geeky water cooler or your buddy’s tout  costume party if you can relate what you’re doing on the Web to MVC and with your friends might be doing And second (and possibly a bit more useful) if you can identify what your scripts do you’ll often  be able to figure out more quickly how to do those things In the case of you see that it’s mostly a controller Thus makes perfect sense to hand some information to a script that’s mostly a view like and let that script handle display of that information to the user.

So needs to provide a message (because it knows that deletion has
occurred) but it must let something else handle the actual display Therefore you can add a message to your redirect Go ahead and connect this new message to a new request parameter success_message at the end.

Model-View-Controller Well. Sort Of

II Redirect to show_users to re-show users (without this deleted one)

Model-View-Controller Well. Sort Of

Even before you go back to working on your view code in show_user.php you can test this out. Visit show_user.php delete a user, and then look closely at the browser bar when you’re taken back to show_users.php. You should see the success _message request parameter with the value set to your message.

JavaScript alert Reduce

Here you are, back to show_users.php and you have an incoming message.

What needs to happen when that message is received Probably the easiest option is to go back to JavaScript and use an alert dialog box. This is the equivalent of the confirmation dialog box you used before deletion (page 349), so it’s a nice symmetry.

AN ALL-JAVA SCRIPT APPROACH

One approach would be to write a JavaScript function that you can add to JavaScript doesn’t directly support reading request parameters, so you’d have to do a little parsing to get at them. You’d need something that uses regular expressions to pick apart the window location pref property, which is the URL the browser has:

AN ALL-JAVASCRIPT APPROACH

You could then call this function in the following way to get at the success_message parameter (probably in another JavaScript function):

AN ALL-JAVASCRIPT APPROACH

Then (after uncrossing your eyes from all the forward and backslashes in get_ request _param_value), you could issue an alert:

AN ALL-JAVASCRIPT APPROACH

There’s certainly nothing wrong with that approach It works fine and you’ll see something similar to the message you add this code in to the head section between script tags.

AN ALL-JAVASCRIPT APPROACH

AN ALL-JAVA SCRIPT APPROACH

Before you start wondering how to piece all this together though there might just be a better way.

YOUR PHP CONTROLS YOUR OUTPUT

The all Java script approach discussed in the previous section makes a subtle but important assumption the page-the HTML css and Java script delivered to the user via his browser has to make all the decisions about what to do what to show and how to act This means that there’s JavaScript that must figure out whether the success message parameter was passed along JavaScript to parse the request URL and find the value of that parameter and JavaScript that conditionally displays an alert.

Here’s the thing isn’t limited in the same way that the page it outputs
is Just because the HTML and JavaScript that’s ultimately output is unaware of whether there’s a request parameter doesn’t mean that your script that output is unaware In fact it’s simple to get a request parameter in you’ve done it tons of times

YOUR PHP CONTROLS YOUR OUTPUT

YOUR PHP CONTROLS YOUR OUTPUT

That’s a win by any measure of accounting .

Here’s something big to sink your teeth into: you’re in control of what goes to the client Your script can make decisions about what to output As a result. in your PHP you can do something like this

YOUR PHP CONTROLS YOUR OUTPUT

That’s all taking place on the server before you’ve done any output Then if you have a message to show-and only if you have a message to show-you can simply add a few lines of Java Script into your HTML output

YOUR PHP CONTROLS YOUR OUTPUT

Put all this together, and here’s the new, improved

YOUR PHP CONTROLS YOUR OUTPUT

YOUR PHP CONTROLS YOUR OUTPUT

YOUR PHP CONTROLS YOUR OUTPUT

What you’ve adore here is a big accomplishment in PHP programming. Instead of relying on your output to make complicated decisions you’re making most of the decisions in your PHP and then tailoring your output as a result Thus one script depending on the decisions it makes-might push out two three four or even more variations of the same output First then take your script out for a test drive If you still have a browser up with a URL  just reload that page to get the new changes  You should see a nice pop-up window with the message passed through the URL.

YOUR PHP CONTROLS YOUR OUTPUT

Take a look at this page’s source code to see what’s so cool about it.shows that there’s a hard-coded alert for the message passed along. Change the message in the request URL and you’ll see the HTML change to match.

YOUR PHP CONTROLS YOUR OUTPUT

YOUR PHP CONTROLS YOUR OUTPUT

Now, delete all of the request parameters from show_users.php in your URL bar and then go to the page again. The alert box should go away, and so should the JavaScript in the HTML page that  generates.the resulting source code: the window on load function has vanished .

YOUR PHP CONTROLS YOUR OUTPUT

YOUR PHP CONTROLS YOUR OUTPUT

alert Is Interrupt

You have a nice bookend of notifications now. A confirmation box requires a user’s OK before deleting a user, and another alert informs her once that deletion’s done So, from a functional point of view, you’re ready to move on.

This is one of those moments when you have to move a bit beyond web programming and start thinking about web design or better web Usability is just a high end way of saying What’s the user experience like With regard to deleting a user deleting a user you’re doing well Although you might use something like j Query to present a better looking dialog box you’re doing all the right things interrupting the user to ensure that she truly wants to delete a user and you’re requiring a double action (click once to select delete; and click once more to ensure that’s the intention) .

What about after deletion Yes you need to let the user know that the deletion has occurred But do you need to effectively shut them down until she clicks OK Ideally you’d let her know about deletion but make it a little less interrupter.

And that’s a general principle for web usability if you’re going to make your user take her hands off the keyboard and click a button make sure it’s worth her while In this case there’s a risk you’re being annoying Why do I have to click again I just clicked twice to delete the user in the first place.

 

Posted on January 13, 2016 in Listing Iterating and Administrating

Share the Story

Back to Top
Share This