Category: Poise.sg

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
   jQuery(“#parentNodeID”).append(data);

   })

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
   eval(data);

   })

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
   jQuery(data).each(function(index){

   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.

Thus far functions that allow for the creation of accounts for the three user roles have been created. People coming to Poise.sg will be able to login to Poise.sg using their facebook connect details and create an account type of their choice. There are basically 3 defined account types.

• Models & Talents (Male & Female)
• Agents
• Media Houses / Production Houses / Advertising firms / PR firms

Functions accessible by Models & Talents are well defined.

Thus far there is a lack of differentiation between the user roles of Agents and Media Houses system wise. There is almost no difference between these two roles with the exception that when media houses attempt to contact models directly, the notification gets routed to their agents as well as the models.

This is the main issue of concern which I have been pondering over these past few days. I will need to identify the key value an agent contributes to this process other than just being the middle man whose sole purpose is to pass information along the channel. From a superficial perspective an agent is one that simply contributes by passing information along. However in this new system that will be known as Poise.sg, information will be made transparent, thus eroding the role of agents as information transferrers. As such an agent might in fact come to see Poise.sg as a threat to their role in the supply chain, thus resist the adoption of the use of the Poise platform.

However from an industrial perspective, why is it that Media Houses / Production Houses / Advertising firms / PR firms choose to engage the agents on some occasions and by pass the very same agents during other occasions? There must indeed be a defining difference between these two decision outcomes, therein lies the true value of agents.

Ideally when Poise.sg is eventually launched, this platform should safeguard the interest of all three parties. The only way I could envision this to be possible would be to ascertain the core value adds these three roles contribute to the supply chain and enhance the effectiveness of their roles by providing them with supporting software functions. Thus far I have approached 3 modelling agencies of which I am closely acquainted with for feedbacks and insights into this issue.

1. Esther from Ezen Models
2. Justin from Style House
3. Kirk from Perspective Models

Hopefully the insights, I gain from this round of interviews would lead me to the solution of this wall I hit.