Creating an array that loops out on the frontend - Don't Repeat Yourself? Entire Code Here

Don't repeat yourself

I know of the "Don't repeat yourself". Still it's getting messy in some places. The code below contains three blocks of code.

They are similar in some ways and different in others. It doesn't follow the same pattern in all ways.

What it does

It creates an array that I loop out on the frontend.

Question

Is there any better way to do this kind of stuff? Less messy, better structure?

$message_start = '&lt;strong&gt;h2 tags&lt;/strong&gt; - ';
$message_end = '&lt;span class="counter"&gt;' . $this-&gt;count_h2 . '&lt;/span&gt;';
if( $this-&gt;count_h2 == 0 ) {
    $message = 'No tags found. Add some!';
    $array['content_editor']['count_h2']['status'] = 2;
} elseif( $this-&gt;count_h2 == 1 ) {
    $message = 'Some found. Too few!';
    $array['content_editor']['count_h2']['status'] = 1;
} else {
    $message = 'Many found. Great!';
    $array['content_editor']['count_h2']['status'] = 0;
}
$array['content_editor']['count_h2']['message'] = $message_start . $message . $message_end;
$array['content_editor']['count_h2']['count'] = $this-&gt;count_h2;

$message_start = '&lt;strong&gt;h3-h6 tags&lt;/strong&gt; - ';
$h2_h6 = $this-&gt;count_h3 + $this-&gt;count_h4 + $this-&gt;count_h5 + $this-&gt;count_h6;
$counter = ( $h2_h6 == 0 ) ? '' : $h2_h6;
$message_end = '&lt;span class="counter"&gt;' . $counter . '&lt;/span&gt;';
if( $h2_h6 == 0 ) {
    $message = 'No found. Add some!';
    $array['content_editor']['count_h3_h6']['status'] = 1;
} else {
    $message = 'Found, great!';
    $array['content_editor']['count_h3_h6']['status'] = 0;
}
$array['content_editor']['count_h3_h6']['message'] = $message_start . $message . $message_end;
$array['content_editor']['count_h3_h6']['count'] = $this-&gt;h2_h6;

$message_start = '&lt;strong&gt;Title keywords&lt;/strong&gt; - ';
$counter = ( $this-&gt;found_keywords1_post_title == 0 ) ? '' : $this-&gt;found_keywords1_post_title;
$message_end = '&lt;span class="counter"&gt;' . $counter . '&lt;/span&gt;';
if( count( $this-&gt;keywords1 ) == 0 ) {
    $message = 'No primary added.';
    $array['content_editor']['missing_keywords1_post_title']['status'] = 2;
} elseif( $this-&gt;found_keywords1_post_title == 0 ) {
    $message = 'No primary found.';
    $array['content_editor']['missing_keywords1_post_title']['status'] = 2;
} else {
    $s = ( $this-&gt;found_keywords1_post_title != 1 ) ? 's' : '';
    $message = 'Primary found.';
    $array['content_editor']['missing_keywords1_post_title']['status'] = 0;
}
$array['content_editor']['missing_keywords1_post_title']['message'] = $message_start . $message . $message_end;
$array['content_editor']['missing_keywords1_post_title']['count'] = $this-&gt;found_keywords1_post_title;
Architecturally, I'm adverse to hard-coding HTML tags within PHP code. If, for example, you wanted to migrate the code base from PHP to another language (Java, Python, Ruby, Go, Haxe,  whatever) then you have to rewrite both the logic (PHP) and the presentation (PHP) code.

Consider decoupling the logic from the presentation so that you can change how the data appears without having to change how the data is retrieved. This simplifies switching implementation languages and opens the possibility to create different views of the same data for different devices.

To do this, you have to create an interface or contract between the logic and the system that renders the logic for the user. Fortunately, this is where XML excels.

Instead of hard-coding &lt;strong&gt;, you would create an XML document that represents the information you want to display. The XML document becomes the contract between the logic and presentation, which allows both to vary independently. Once the XML document is in place you can pass it to an XSLT Processor to generate the desired HTML content.

This offers the following advantages:


Decoupled. The presentation logic moves to XSLT, completely decoupling it from the PHP code.
Migration. Migrating from PHP to another language means the presentation logic need not change.
Devices. It becomes trivial to change the presentation for different devices (use a new template).
DRY. With display logic in a central location, duplicated code is easier to eliminate.
Databases. Many databases now allow constructing XML documents within stored procedures, eliminating complex code readily expressed in SQL.
SaaS. It simplifies creating a SaaS API -- transforming XML to JSON is fairly easy a solved problem.


This has the following disadvantages:


Effort. Migrating to an XML/XSLT solution for presentation takes a lot of work.
Knowledge. Introduces a second programming language (XSLT) into the software.
Developers. Far fewer developers know XSLT than PHP.
XSLT 1.0. Using PHP, the processor is limited to XSLT v1.0 (many great features are in XSLT 2.0).
Bugs. The XSLT Processor has some pesky known bugs, which could be avoided by moving to XSLT 2.0 with the SAXON processor.