A javascript decision on the use of jQuery on PHP WordPress PHP (JSON, Raw HTML or Javascript)

Recently, I have been focusing my programming efforts on mainly Poise.sg. Poise.Sg is built using WordPress as the backbone, the choice of which I stated in a previous article (choice of platform for a new concept). To date, my choice using wordpress has proven to be a sound one. I have been able to achieve the 3 following objects through the use of wordpress

  • Ensuring conformity in look and feel
  • Accomodate multiple different layouts
  • Maintain role based access control to specific views
  • Incorporating new external Javascript and PHP libraries into WordPress as a plugin

Now as the project progresses, I am faced with a software architectural issue. This has to do with the way the jQuery library is ultilized. Due to the fact Poise.Sg is a heavily Ajaxed system, there are many instances of the client browser doing an off the screen call back to the server via an Ajax Post method.

Due to the flexibility of the jQuery Library, there are three different methods available I could handle data transfer between the server and the client browser. They are

  1. To return raw HTML from the server and append the parent HTML DOM node via the method
    jQuery.post(‘server.php’, {data:”something”}, function(data){

    //data is a raw HTML


  2. To return javascript, to be executed in the function that will handle the response data
    jQuery.post(‘server.php’, {data:”something”}, function(data){

    //data is a series of javascript


  3. To JSON object to be interated in the function that will handle the response data
    jQuery.getJSON(‘server.php’, {data:”something”}, function(data){

    //data is JSON Object and can be iterated through with a for loop

    var value = jQuery(this).val()



After having tried each method, I have come to realize there are Pros and Cons to each of the three methods.

Method 1 was is an easy and straightforward method to employ. However, it results in data and presentation being mixed in the response. A change presentation layout would translate into the need to go back and edit the codes sitting in the server end. It does not cater for the eventual possibility of data source reuse due to the tight coupling between data and presentation. The repercussion is the need to create a different ajax server method each time a server call needs to be made from a different view from the client end.

Method 2 is a somewhat less straightforward method to employ as compared to method one. It is a doubly bad option. Not only does it face the none data source reusability issue described in method 1, it also face the possibility of PHP introduced javascript error, in the event whereby PHP inserts invalid characters into the javascript string or integer location.

Method 3 does allow for flexible reuser of data source, since the styling is handled at the client side Javascript level, while the server side is only responsible for generating valid JSON responses. This means multiple different views with drastically different layouts could share the use of the same data source. The only downside to this method is similar to the PHP introduced error as described in the method 2. The main difference is that instead of PHP introducing invalid characters to disrupt the javascripting, it introduces invalid characters in the value JSON fields thereby rendering the JSON response invalid.

For the sake of system extensibility on Poise.sg, I opted for method 3. The down side is that while the content will be mainly user generated as similar to ThingsToDoSingapore.com, there will be instances when the result will not be displayed as generated by the user due to their use of invalid characters.

These are my thoughts for today. Being the workaholic as I am, I have over the course of a few hours today (a Sunday) finished the search form on Poise.sg and will now take a break till tomorrow.

Leave a Reply