I created a WordPress site for a client who needed to support both English and Español versions of their content, which involved using a plugin called MultilingualPress that creates relationships between sites for each language.
I developed the site locally on my server, and then after they created some content, migrated it to their hosting service.
Once in a while, I run across a situation where I need to import data from a spreadsheet into a database.
If the data is to update a single table, this is pretty straight forward. On the other hand, if the data is modeled as a set of tables it gets a bit more messy. Continue reading
If you read my previous post (WordPress Recovery), you know I’ve been writing some code to recover my old posts. It occurred to me I could take a small segment of what I’ve been doing with that code to demonstrate my approach to TDD.
Since I’m a hacker from way back, and also because I was in semi-panic mode about losing the content, I didn’t approach this task with testing in mind. Now that doesn’t always result in bad code: I’ve been doing this long enough that I can usually think through a fairly good model and code something that isn’t one long method full of inline code.
In this case however, once I had started coding, I realized again that this was an opportunity to practice coding the “right” way. I had already begun with a Maven project, and generated unit tests as I went through the process of starting to build the code, so I had at least some good functioning unit tests.
Well, I have the basics of my blog recovered now, so almost all of my posts going back several years are once again available.
In my last post titled Lesson Re-learned: Backups !, I admitted that I had committed the cardinal sin of making changes to my web site without doing a backup first (walking the tightrope without a net).
Luckily for me I had installed the WP Super Cache plugin, so all of my content actually still existed as static files, and being a bit of a hacker, I was able to throw together some code to effectively recover my posts.
I decided I’d walk through creating a new app to replace one I’ve used for years on my iPhone that no longer appears to be maintained. The app in question is called GasBag which as near as I can tell stopped being updated in 2009 (see: http://blog.jam-code.com/).
I could just write a quick and dirty web app to store my mileage, but I figured I’d approach this as an exercise in building an iOS application with a design first approach.
At a high level, what I want is an app that easily captures my mileage, and allows me to save that information somewhere that won’t get destroyed. There are a number of features that GasBag had that I liked (for instance being able to send an email with my mileage information), and a number that it doesn’t have that would be nice (like allowing me to use it for multiple cars, or to do some data capture from a gas station receipt).
I ran into an odd problem with the way Cake is coded that tripped me up for a couple of days. Because I hate it when things don’t work the way I think they should, I spent way more time debugging this than anybody should.
I got my basic RESTful service working for the VolunteerCake project, and everything was working swimmingly, until I needed to turn on debug to figure something out …
When I had the debug level set to less than two (2) calling the action I was interested in with an extension of “.xml” was working fine. I got back the XML representation of the data in the action I was interested in returned with content-type of “application/xml”. In Cake, if you turn debug to 2 (or 3) it will dump out the SQL that was run in an HTML table.
The problem is that this HTML table is actually spit out after the rest of the view, meaning that my RESTful service no longer has a well formed document to display. Additionally (for reasons I’ve yet to isolate), when this happens, the document is returned with a content-type of “text/html” instead of “application/xml” as expected. Neither of these things would be acceptable if the site is to provide web services, since it would mean the web services would be broken as soon as somebody needed to debug.
The workaround for this is to manually reset the debug level when the extension of “xml” is detected. Since the debug data is useful, and it’s just the SQL that appears to break the XML, I asked on the IRC channel what the last place I could set the debug might be. The suggestion was to put it either in the afterFilter, or the end of the view itself.
I found that if I put the following code into the beforeFilter method, I could prevent the problem with the price of losing my debug output:
|
1 2 3 4 |
if ($this->params['url']['ext'] == 'xml'){ Configure::write('debug',1); $this->RequestHandler->respondAs('xml'); } |
That same code placed in the afterFilter method gave me the debug output in a well formed XML document (excluding the SQL table), as did placing it in the view itself. This leads me to believe that when debug > 1 there is some code that happens after the beforeFilter that is not setting the content type to “application/xml” as would be expected from our routing rules.
Being the bulldog that I am, I dug into the Cake source code to see if I could figure this out. I found the spot where the SQL table was being built, which turned out to be in the showLog() method of the dbo_source.php, which is called by the close() method. Since the close() is called after the view is finished, and the showLog() method simply prints the data, that explains why it breaks the XML. It definitely breaks the MVC encapsulation, since the data gets dumped into an HTML table and spit out after the view is complete.
On the IRC channel, it was suggested that I try creating a data source that would override the showLog method and spit that table out to a table, which might be worth trying.
I posted my question on the CakePHP Google Group and got the useful suggestion to use the FirePHP plugin which basically writes the log data to the FirePHP plugin so it can be displayed in FireBug. So my approach will be to write a dbo_mysql_firephp.php class that does just that. This will at least resolve the MVC encapsulation issue and keep my view relatively clean.
I still want to figure out exactly why the content-type isn’t getting set properly, but for now I have a workaround that I’ll use, and I’ll add the FirePHP debugging to solve the well-formed XML issue if I ever do figure out the content-type problem.
Off to set up my FirePHP plugin and build the dbo class now …
I’m on a quest to make my application provide RESTful web services. After much digging, I found a post by Chris Hartjes at http://www.littlehart.net/atthekeyboard/2007/03/13/how-easy-are-web-services-in-cakephp-12-really-easy/ that helped a lot.
Turns out that Cake has some really nifty built in support that can be turned on really easily. For basic XML support, all you need to do is to add a couple of lines to your routes.php file to allow Cake to handle XML. This is pretty well described in the Cookbook at http://book.cakephp.org/view/477/The-Simple-Setup
So for my VolunteerCake project I added the following lines to my routes.php:
|
1 2 3 4 5 |
/** * Add in support for web services by enabling generating output based on extension */ Router::mapResources(array('events', 'event_josb', 'groups','jobs', 'slots', 'users', 'user_groups','user_slots')); Router::parseExtensions(); |
The mapResources() does the magic that maps the REST requests to the actions in the controllers, and the parseExtensions() sets up Cake to do some other routing magic when the request has a “.xml” extension.
So now if I call any of my actions and append “.xml”, Cake changes the response type and view to return XML. Next we need to add the view for the XML, which goes in the xml directory under the view we are REST enabling (e.g.- for jobs, we have a views/jobs/xml directory where the view CTP files need to be placed).
First I created the xml directory under the views/jobs folder, and next I created an index.ctp. This is a very simple file, which Cake’s XML helper to spit out the data with the following code:
|
1 2 |
<<a class="zem_slink" title="Steve Jobs" href="http://www.crunchbase.com/person/steve-jobs" target="_blank" rel="crunchbase">Jobs</a>> <!--?php echo $xml--->serialize($jobs); ?> |
Now to get the XML to display, all I have to do is create the appropriate views for my REST actions.
So for example if I go to the app/jobs action, I would normally see the XHTML representation of the page like:
Then if I append “.xml” to that same URL, I get the XML back as shown in the following screen shot:
Next we need to do the view.ctp to provide support for sending back the data for a specific job by ID. This is practically identical to the index.ctp, except we’ve modified the code to use the variable $job instead of $jobs (since that’s what Cake returns):
|
1 2 3 |
<Jobs> <?php echo $xml->serialize($job); ?> </Jobs> |
This allows us to get the behavior of being able to get the XHTML for a specific job by using a url like /jobs/view/1 as shown:
Then by appending “.xml” to that same URL, we get the XML for the job with ID of 1:
You may notice that the XML for this Job has a lot more data than we saw when we got the list for the specific Job. The XML from /jobs.xml is only one level deep, while the data from /jobs/view/1.xml has a hierarchy of a job having slots, which in turn has a job, user_slot and user.
That happened because the index action was set up to only get the data from the Jobs, while the view action had recursion set in order to gather all the related data. By setting the recursive var to 0 (zero) in the index action, we get no children, while in the view action we set the value to 2 (two) which tells cake to fetch all the HABTM data (see: http://book.cakephp.org/view/439/recursive for more on this). Alternatively we could do a specific find and modify which bits of data we populate in the controller to determine what data gets spit out in the XML (this would alleviate the one potential downside to this approach which is that ALL of the data fields and tables are currently being placed out in the XML stream).
The basic point here is that we now have a working RESTful service (at least as far as fetching data) that doesn’t require a great deal of specific view code.
Next: completing the RESTful CRUD …
