Philly Give Camp 2010: Part 5
Posted in events on July 6th, 2010 by Jamie – 1 CommentThe Builder
To keep the teams working as separately as possible with the least interference, we decided that the PAAL Builder, the tool used to build student schedules and lessons, would be completely HTML and Javascript. That means that there would be no server-side code, no ERB or HAML template files, and no Rails special sauce. This allowed the designers to work without developer support, and allowed developers who did not know Ruby or Rails to work solely on Javascript code. The Builder would interact with the API via ajax calls with JSON responses. A simple format for the response envelope was designed:
{
version: 0.1,
error: '',
data: {
task: {
id: 1,
name: 'Brush Teeth'
}
}
}
This is an example response upon the creation of a task with the name “Brush Teeth.” On each request, the error property would be checked to make sure that it was blank. The version property would also allow changing the API in the future without breaking the application.
In the previous post I discussed the problems of having a simple API. One common scenario is to create a task and link it with a parent task. This would happen if you wanted to create a task like “Brush Teeth” and steps underneath it like “get toothpaste,” “get toothbrush”, “brush front teeth.” Here is the code necessary to do that (I am just posting the necessary jQuery calls rather than the wrapper functions I wound up writing):
// create the task via a POST
$.post(
'/tasks',
taskData,
function(envelope, textStatus, request) {
if ( envelope.error != '' ) {
// error
}
else {
// on success, tie the newly created task
// to a parent task
function callbackSuccess(newTask, envelope) {
$.post(
'/task_parents',
{
task_parent: {
task_id: newTask.id,
task_parent_id: some_parent_id
}
},
function(innerEnvelope, textStatus, request) {
if ( innerEnvelope.error != '' ) {
// error
}
else {
// success!
}
},
'json'
);
}
callbackSuccess(envelope.data.task, envelope);
}
},
'json'
);
Wrapper functions make this simpler to understand, but the fact that it requires two posts troubled me. Still, I avoided adding a new method to the API to do this all in one step.
When we were working on the project, the designers and another developer worked mostly on basic UI. I then worked on “installing the plumbing” as I put it, making all the API calls and using the live data. A lot of this plumbing went into the product after Give Camp. One aspect of the project I found hard after Give Camp was figuring out how a feature or UI element would work. Often, I’d be hooking up the plumbing, but be unsure of whether they wanted a stand-up shower or a bathtub. Both would get the job done, but I wasn’t sure what they had in mind, and it wasn’t clear from the design.
Part of this was due to the fact that I didn’t have the most recent design. We switched versioning systems two times during the course of Give Camp, and repository locations 3-4 times. Part of this was due to lack of notes or obvious visual stimuli. In general, after Give Camp was over, it was hard to coordinate with each other.
