[e_i_pi]

I've started another topic asking about code separation in the PHP Developer forum, but I don't want to ask specific code questions there. The type of site I am writing is not a straight-up content display webpage, it's heavily DHTML and so there are various aspects of code design that I am having trouble nutting out in terms of code separation. Now, I'm not interested in posing every question I have here, but I'd like to get some pointers from people on some "basic" code problems and how you would separate them out or rewrite them.

The example below is pretty simple. Draw a table, but populate the rows with data returned from a MySQL query. I'd just like to know how you would go about separating this code out, so the HTML does not sit with the PHP. I can see various approaches, but I don't know which would be best. I have been simply writing echo statements and wrapping the entire file contents in PHP tags, but that keeps the HTML with the PHP, which isn't best code practice.

<table>
	<tr>
		<th>Date</th>
		<th>Title</th>
		<th>News</th>
	</tr>

<?php
	$sql = "SELECT Date, Title, NewsItem FROM News";
	$result = mysql_query($sql);
	while ($row = mysql_fetch_array($result))
	{
		$html = "<tr>";
		$html .= "<td>" . $row[Date] . "</td>";
		$html .= "<td>" . $row[Title] . "</td>";
		$html .= "<td>" . $row[NewsItem] . "</td>";
		$html .= "</tr>";
		printf($html);
	}
?>

</table>

[Dormilich]

it depends on whether you use a templating engine/framework or not.

if you do, you just have to replace the placeholder in the template file with the generated HTML.

one way to generate HTML from database results is described here.

if you don’t use a framework, file_get_contents() and str_replace() are good friends.

[e_i_pi]

Hmm, this looks like a lot of work. I'm not against learning more, but this does look like a steep learning curve, so I hope you intend on sticking around DIC for a while, because I'll no doubt have a lot of questions.

In that other thread, the first good improvement you show obviously has benefits - it splits away the output template, and simplifies the code. This is easy stuff for me, because it doesn't expand upon my current skillset.

Further on you show how to achieve this with OOP and PDOs. These are two areas I have no experience in. I come from a modular programming background, so have been constructing my code in a modular fashion, but I have noticed that the way I have been separating out my code recently has been OO in design.

A particular custom function I use is loadModule($str), where the $str is the module name (ie - directory name) of the module I want to load up. A particular page I write might be limited to five lines of code, for example:

include headers.php;
loadModule('TitleBars');
loadModule('GenericHomePage');
loadModule('RandomQuotation');
include footers.php;

When a module is loaded, it goes through three steps:

• Includes a file '_functions.php' that resides in the module directory, and contains generic functions specific to that module
  
• Gets a script file '_scripts.js' that resides in the module directory, and contains all Javascript specific to that module
  
• Includes a file '_module.php' that has the initial HTML output of that module (if any)

After that, it is all handled by AJAX calls, which are defined in the _scripts.js file, and call particular php files within the module directory (eg - './TitleBars/MaximiseViewwindow.php').

So in essence, the initial loading of the module is like the __construct method, and the AJAX calls are like the public functions within the class. Unfortunately, the AJAX functions encapsulate the HTML templating and SQL queries, which I think is where I'm coming unstuck when trying to separate out code. The particular problems I face now are:

• If I continue the way I'm going, the code is convoluted and hard to gain assistance from others on
  
• If I continue the way I'm going, any developers I get on board will have a steep learning curve
  
• If I change my methods, I'm going to have to learn OOP
  
• If I change my methods, I'm going to have to learn PDO
  
• If I change my methods, any developers I get on board will be able to pick up thing more easily

This is a daunting task, but I'm not looking at developing a simple website. The vision I have is quite complex, and the prototype I developed a year ago is in production and definitely not at the simple end of the scale. I just don't want to get bogged down rewriting code in an unfamiliar style, and have the first full version of the site take 2-3 years to complete.

This post has been edited by e_i_pi: 14 February 2011 - 03:51 PM

[JackOfAllTrades]

Accessing an associative array like this

$row[Date]

you should be enclosing the string-based keys in quotes, like this

$row['Date']

[e_i_pi]

JackOfAllTrades, on 14 February 2011 - 03:57 PM, said:

Accessing an associative array like this

$row[Date]

you should be enclosing the string-based keys in quotes, like this

$row['Date']

Oh, yeah I normally do, that's just a small oversight. I just whipped that code up quickly as an example of a common type of problem I face when coding.

[Dormilich]

e_i_pi, on 14 February 2011 - 11:50 PM, said:

So in essence, the initial loading of the module is like the __construct method, and the AJAX calls are like the public functions within the class. Unfortunately, the AJAX functions encapsulate the HTML templating and SQL queries, which I think is where I'm coming unstuck when trying to separate out code.

sounds wrong. neither AJAX nor HTML have anything to do the way PHP works. (unless I misunderstand the intention of the code)

you should write all AJAX files as <script> includes. the server-side code of the AJAX is not influenced by that.

SQL queries don’t belong in the output section either, put them in your library, they only need to be callable.

e_i_pi, on 14 February 2011 - 11:50 PM, said:

• If I change my methods, I'm going to have to learn OOP
  
• If I change my methods, I'm going to have to learn PDO

nothing wrong with learning PDO. for starters, you can treat it like a couple of functions. besides that, it makes switching databases a piece of cake (many professionals use PostgreSQL, and you would have to rewrite your complete database code were you not using PDO)

[e_i_pi]

Well, I've finally managed to rewrite the simplest of my modules into a class. 5 lines of code becomes about 50 lines of code lol. I figured I'd start on a simple (and probably unnecessary) conversion to get the hang of the basics and move from there. I've got it working, so I'm at least starting to understand OOP and PDOs a bit. I still think OOP was invented by the devil

[Dormilich]

you don’t have to use OOP for the sake of itself. you should use it where it makes sense.

[e_i_pi]

Dormilich, on 15 February 2011 - 12:05 AM, said:

you don’t have to use OOP for the sake of itself. you should use it where it makes sense.

Oh yeah I understand that, but I've found the best way to learn is to start with a simple problem, that way I narrow down all the potential places the code could go wrong

[Dormilich]

I wouldn’t call converting a modul into a class simple …

for starters, try some classes where actual data is concerned (so you can practice on data encapsulation)