Standardizing on Messaging PHP Help

There’s another issue to consider Is a success message the only type of message you might need to display What if you have an error that doesn’t rise to the level of requiring handle_error What if you need a status message, perhaps something like Please log in before attempting to delete a user.

These are all similar cases you want to present a message to the user but you don’t want to interrupt his flow You want to add content to the page but Java Script’s alert and confirm aren’t the best choices.

Additionally you’d ideally make this a generic functionality You don’t want every script to have to output 5 or 10 lines of code It would be nice to have your output do something like this.

Then, this function would simply “take care of things,” whatever that ends up being For example for a success message you might get a banner message across the top of a page.

Standardizing on Messaging

Standardizing on Messaging

The HlML for success messages is simple:

Standardizing on Messaging

similar fashion Figure 11-15

similar fashion Figure 11-15

Here’s the HTML for the error It’s identical to the success message with a different class on the inner

Standardizing on Messaging

Building a New Utility Function for Display

Once again it’s back to thinking generic Rather than worrying about the specific success message passed  what’s the more general form of a success message

Building a New Utility Function for Display

That’s not real PHP of course you’d really want to do this

Building a New Utility Function for Display

That’s easy! You just need a new function that takes in the message

Building a New Utility Function for Display

The Right to Readability

There are about as many ways to write a function like display success message as there are letters in the alphabet. You could use sprint to insert the message You could combine the multiple echo calls into a single line (using echo or sprint f) You could output raw HTML and interrupt that HTML with PHP by using case your solution would be just fine.

The \n’s are another curiosity. They’re just to make the viewed source a little cleaner. Without them, the output would look something like this.

The Right to Readability

It would be just one big line of HTML With the line feeds the user sees nothing different HTML doesn’t care a bit about those feeds But if you viewed the source you’d see a much nicer bit of HTML

The Right to Readability

The Right to Readability

Are the \n’s necessary Not at all Do they help the user Nope But they definitely do make debugging and readability a bit simpler So should you use them or not, and do they go with echo or sprint f or both.

You’re at the place in your PHP journey where style and personal preference are more important than right and wrong You can use sprint f everywhere for queries and output and everything in between You can use echo for output and sprint f for queries Or more likely you’ll use whatever comes to mind when you’re writing the particular script you’re writing.

The same is true with in and line feeds Sometimes you’ll work hard so that the HTML out put is nice and clean and easy to read Other times you’ll realize that you could spend hours trying to get things to look good for that rare person who Views Source Then again you’re that rare person so sometimes the effort makes perfect sense.

As it stands, this function works well How about error messages You could use something similar.


Look closely: both of these are outputting the messages <div>. That’s no good. You need something that can handle C error types Then that sort of Parent function can pass the individual messages to smaller functions each of which handles success c errors.

Building a New Utility Function for DisplayThe Right to Readability

That looks better But again look closely Does it seem like you might be seeing double.

Duplicate Code Is a Problem Waiting to Happen

The problem with the code you just completed is a bit subtle which is why it can be so nasty Look how close these two functions are to each other.

Duplicate Code Is a Problem Waiting to Happen

That’s a Jot of identical code all for just one change-in this case the class of the <div> in each. Anytime you see code that’s this similar you should immediately be thinking Huh oh That’s fragile code That’s something you want to avoid For a much more stern lecture on why this is important.

Duplicate Code Is a Problem Waiting to Happen

Duplicate Code Is a Problem Waiting to Happen

Because there’s so much repeated code you can consolidate these functions.

Duplicate Code Is a Problem Waiting to Happen

That’s much better It’s clear succinct and very DRY In fact you can take things even further and define the allowed message types as constants to make your code even neater.

Duplicate Code Is a Problem Waiting to Happen

Using this, you don’t have to remember whether the message type for an error was “ERROR” Or “error” or “errors” or something else altogether. The constant handles that mapping for you.

coding

coding

View and Display Code Belongs Together

You now have another script: Remember, you’re creating not just utility code but nicely organized code. Even though you could put display_messages and display message in that’s not good organization.

Taking time now to build groups of functions in scripts that ~re usefully named is well worth your while. When you’re writing a script like  that handles display, you immediately know you can include view and get helpful functions. On the other hand, in a script like that doesn’t do any display, you can skip

Posted on January 14, 2016 in Handling Images and Complexity

Share the Story

Back to Top