This is a design question. I have data that needs to go into an HTML table, which will later be manipulated by the user. Basically the user will be able to select items in the table rows.
I have two options - in both cases I'm using AJAX to get the data:
-
Create the HTML code using PHP on the server side, send it to the client as HTML. The user then manipulates the table using Javascript (jQuery, essentially).
-
Send the raw data to the client using JSON, then use jQuery to both create the HTML and later manipulate it by the user.
From a design/ease of coding/beauty point of view, which approach is recommended? Thanks for any insight.
Source: Tips4all, CCNA FINAL EXAM
Why to generate the HTML in PHP:
ReplyDeleteJavaScript should define the behaviour, not the content.
Creating in JavaScript requires more markup (multi-line strings aren't as easy as in PHP).
It's harder to maintain if your HTML is generated in several places (PHP & JS).
You could use jQuery's DOM manipulation functions to create your HTML, but you're shooting yourself in the leg on the long run.
It's faster to create the HTML at the server than on the browser (in computational sense).
Looping is easier with PHP – it's easy to generate table markup.
You retain some kind of combatibility if the user has JavaScript disabled if you output the markup on page load.
Why to generate the HTML in jQuery:
You'd save some bandwidth.
Binding events might be simpler.
So, I'm in favour of the first option, generating the HTML in PHP.
Visual comparison of the two methods, creating a simple table.
Option 1, using PHP:
// PHP
$html = '<table>';
foreach($data as $row) {
$html .= '<tr>';
$html .= '<td><a href="#" class="button">Click!</a></td>';
$html .= '<td>'.$row['id'].'</td>';
$html .= '<td>'.$row['name'].'</td>';
$html .= '</tr>';
}
$html .= '</table>';
echo $html;
?>
// jQuery
$('#container').load('handler.php', function() {
$('#container a.button').click(function() {
// Do something
});
});
Option 2, using jQuery:
// PHP
echo json_encode($data);
// jQuery
$.ajax({
url: 'handler.php',
dataType: 'json',
success: function(data) {
var table = $('<table />');
var len = data.length;
for(var i = 0; i < len; i++) {
var row = $('<tr />');
var a = $('<a />').attr('href', '#').addClass('button');
row.append($('<td />').append(a));
row.append($('<td />').html(data[i].id);
row.append($('<td />').html(data[i].name);
table.append(row);
}
table.find('.button').click(function() {
// Do something
});
$('#container').html(table);
}
});
From a design / ease of coding / beauty point of view, I'd definitely say go with the PHP approach.
If the HTML generated is identical to page HTML you may be able to leverage your existing templating code to generate the same HTML with less code duplication.
ReplyDeleteOtherwise, JSON is typically more common as it tends to be more compact and it allows you to create nodes and assign non-HTML properties like event handlers to them as you go.
If you create your new nodes by creating an HTML string, however, you have to use HTML-encoding to ensure any <, & or quotes are escaped correctly. There's no built-in function to do this in JavaScript like htmlspecialchars in PHP; it's pretty trivial to write one, but no-one seems to bother. The result is jQuery apps that are full of client-side cross-site-scripting security holes, just as we were starting to make some progress of fixing the server-side XSS stuff.
Equally compelling arguments could probably be made for both, but you'll likely be sending less data down the pipe if you go with 2.
ReplyDeleteI really like the idea of putting things like this together on the client side. I found JavaScriptMVC to be a good Framework (the 2.0 Version is based on jQuery) for that because it has client side view templates (though not everybody likes that approach).
ReplyDeleteWith jQuery alone I find it quite complex to create client side views though (because that is not what it is meant for), so you might be better of with putting everything together on the server side in PHP if you can keep your application equally dynamic that way.
Both options have plus and negative points, however andras makes a good point in stating whether the content needs to be indexed/searchable. I personally would opt for option 1 thhough as I believe the architecture would be easier to produce.
ReplyDeleteA similar discussion took place in Why is it a bad practice to return generated HTML instead of JSON? Or is it? with some good points not mentioned in this thread.
ReplyDelete