One of the things I get asked a lot about are the JavaScript widgets that I make, that can be installed on third party websites. The VenueMirror VenueSearch widget at the top of this page is an example of this. The search bar is actually loaded through a JavaScript call that pulls the information from another server. This technique for loading content onto third party websites is not unusual, but it seems there are too few tutorials out there about how to do this. Firstly though – one must question why indeed you would do this.
The Rationale
Placing a form onto a third party website that posts back to a different domain is simple and can be done using plain HTML. However, if the form is populated with a large amount of data, or if the data in the form is dynamic in nature then it makes sense to drive this dynamically. While that sounds logical, to make this easier to understand – reflect on the VenueSearch form above; the VenueSearch form has country and city data, and the choices in the dropdown list are dynamically driven by what cities venues are available in. As new venues are added everyday to VenueMirror, the size of the lists increases – so this in turn means that the options in the dropdown have to be updated. It is not feasible to go around updating partner websites everytime the lists change – so this must be done automatically.
There are many, many examples of such cases – including simple things like booking forms. How many times have you seen forms which include dates that are in the past? Hotel websites are notorious for this, as the third party booking sites are using static forms for the post back of information. These can be cleaned up by using dynamically driven forms.
Hopefully, I have now made the case and rationale clear for why and where dynamic widgets are useful.
The Logic behind the Method
Basic assumptions:
- You have a website hosted at http://www.mysite.com
- You have a need to place forms, or data, on third party websites that are data driven
- The data driving the forms is either housed on, or accessible to http://www.mysite.com
- The third party website can be any other website, but it allows you to place JavaScript code onto the pages (note that WordPress blogs hosted on WordPress.com do not support this)
The method then works like this:
- A dynamic file is created on http://www.mysite.com, if it takes parameters then they must be supplied using the GET method
- The dynamic file can be powered by PHP/ASP/etc etc, it doesn’t matter – but the output must be in plaintext format
- The output is actually syntactically formatted to be in JavaScript
- A naming structure for the third party websites is chosen, and will be the name of the DIV deployed on third party websites
- A snippet of code that references the dynamic file, and the DIV is created, and can be deployed onto multiple third party websites
- When the third party website is loaded, the JavaScript is also loaded, and executes the remote script by making a GET request to it
- The remote script instructs the page to populate the predefined named DIV with new content
Sample Implementation
Step 1 – The dynamic content
Assume that in this implementation, your goal was to announce how many elements existed in your current working PHP directory, your remote code to do this simple task would look like:
<?
$d = dir(getcwd());
$count = 0;
while (false !== ($entry = $d->read())) {
$count++;
}
$d->close();
echo $count;
?>
While not the most useful of scripts by itself, it serves the purpose of being suitably dynamic. The next step is to work on a naming convention that can be used when deploying DIVs on remote servers.
Step 2 – The naming convention
The naming convention comes in two flavours – static or dynamic. A static naming convention is useful if you do not want to do any user/account specific logging, and just want to get your content out there and only expect one DIV to be updated on the page. A dynamic naming convention can be used to uniquely track JavaScript calls, and even have multiple dynamic widgets from the same server on the same page. Static is easy – so let’s go with dynamic to make things more exciting.
A simple dynamic naming convention would be to say we’ll use the name of the site (e.g. kaiesh_com) and append the username of the calling user to it. So if the user account Joe_Blogs were to deploy the JavaScript widget, it would look like: kaiesh_com_Joe_Blogs
The naming convention is totally up to you, there is nothing specific about this part, except for the fact that you must have a convention that you can predict and manage. Dynamic conventions are extremely useful as they allow for extensive logging/tracking.
Step 3 – JavaScript syntactic formatting
Now that the core dynamic functionality, and the naming convention have been defined, the code output must be updated to be JavaScript. And the path to the script must be defined, so assume this is held at http://www.mysite.com/myfile.php. So the code would now read:
<?
$userinput = $_GET['uname'];
$d = dir(getcwd());
$count = 0;
while (false !== ($entry = $d->read())) {
$count++;
}
$d->close();
/* === YOU SHOULD ONLY USE ONE OF THE FOLLOWING === */
/* if you are *not* using jQuery you would use this JavaScript line */
?>document.getElementById('kaiesh_com_<? echo $userinput'; ?>).innerHTML("<? echo $count; ?>");<?
/* if you are using jQuery then you would use this line */
?>$("#kaiesh_com_<? echo $userinput'; ?>").html("<? echo $count; ?>");<?
?>
The above code provides you with two options – one if you were using jQuery, and the other if you were not. So only use one of those – it also assumes that the username will be provided in the GET request through the parameter ‘uname’.
Step 4 – The client side code
So, you have now completed the server side programming, now we have to work on the client side snippet. Remember the naming structure that was defined in Step 2, and how we retrieved the dynamic component in Step 3, that now becomes important in generating the client side code. The code that would be deployed on other servers is now:
<div id="kaiesh_com_joe_Blogs"></div>
<script type="text/javascript" src="http://www.mysite.com/myfile.php?uname=Joe_Blogs"></script>
Step 5 – Deployment
Now the snippet we have made in Step 4, can be deployed into any page, in so long as the file in Step 3 has been created, and is uploaded to http://www.mysite.com/myfile.php
Demonstration
I don’t have time to write a mock up demonstration right now! So please explore the snippet used to make the search bar at the top of the page. I will write a simple demo for this tutorial soon!
Have you implemented dynamic widgets on sites before? Do you have another method? I would be keen to see you have used this. If you have any questions, suggestions, or find anything confusing, please feel free to let me know!
Share on Facebook
Tags: dynamic data, forms, javascript, third party sites, widget
