I am designing the back-end for a web application. I am in a situation where I am unable to collaborate with the front end developer. I also do not like inline HTML\PHP and am not in a position to integrate a template. My solution is that I would keep the front end completely separate from the back-end. The front end would communicate with the back end via AJAX (or jQuery). For example the file upload system would work like this:
<?
//Do stuff
if(!isUserLoggedIn())
die("0-Must be logged in");
//Do more
if(!fileIsTooBigOrNotTheRightType()) {
die("0-Bad files");
}
//Do even more
if(!move_uploaded_file($src,$dst) {
die("0-directory error");
}
echo "1-Success";
?>
The front end developer will simply AJAX the file to upload.php and interpret the response and take the appropriate action on the front end (Show the form, red out some fields, display an error message, redirect to the login form, etc.)
To reduce the number of HTTP queries each page may contain a hidden field with JSON data containing the dynamic elements that will be in place. For example on a private messaging system's inbox page the JSON string may include things such as the number of new messages, who each message is from, and the subject. The front end developer will be able to parse that data and use it any way he likes and is free to create a user friendly interface independent of me.
It is 2012 and I don't think it is wrong to assume the client's have javascript with AJAX support.
TLDR: I am shifting the work of rendering the page (putting elements in their place) to client side javascript. From an efficiency standpoint is this good or bad? It seems like less work the server has to do.
Being both a front and back end developer, my general approach is server-side first, then client side. Make the application work completely and thoroughly without any JavaScript, then move on (or let the front end guy) to the client-side. This ensures that everyone can use your app, even those who don't use JavaScript, such as screen readers and search engines.
What you're referring to is called an API. You make the interface, and then have the frond end developer make API calls to you.
It's possible, though you should be very clear about the specifics of the API (what you can do, and what you can't).
Also make sure you're secure (so that not everyone can access your API).
Other than that, you can do it, sure, no problem.
My suggestion would be to provide a kind of API to the front-end. So, the front-end designer could develop all the HTML, and populate by making javascript calls to your back-end code.
I would then suggest you submit code back to the javascript in JSON format. Javascript handles JSON data structures very well, and the data could then be used to construct the HTML to be injected into the DOM.
I hope I am not too late for the question. I have done a site based on HTML/Javascript(JQuery) - AJAX - PHP, there is no SEO issue to my site, for example, it's No 3 for Google keywords: free restaurant bookings. Plus, Google has suggested a few ways to work for Javascript, e.g. hidden text.
(My views on the question, please correct me if I am wrong) Good: 1. More close to MVP model; 2. Clear structure: User interface on front end, PHP/MySQL on server end, AJAX exchange data in between; 3. Easy to change code as of MVP model; 4. Performance: 2 files should be loaded faster than a big file, front-end for data input and validation, server-end for data process
Bad: 1. Javascript maybe disabled (United States: 2.06%, United Kingdom: 1.29%, France: 1.46%, Spain: 1.28%, Brazil: 0.26%) (http://developer.yahoo.com/blogs/ydn/many-users-javascript-disabled-14121.html) 2. Extra coding: JSON/JSONP, AJAX, deal with arrays in PHP and Javascript.
Finally, I suppose that "my general approach is server-side first, then client side." suggested by Madara Uchiha could be more practice, for example, it's what wordpress is using.