or maybe something uplifting…

CakePHP uses the Prototype Javascript library for its ajax helper class but I’ve come to prefer jQuery. Prototype is a fine library too but I’ve just gotten used to jQuery.

A web application I’m working on needed a ttw html editor so I grabbed TinyMCE and copied in some of the example code and everything seemed to work fine at first glance. Unfortunately TinyMCE has an issue with jQuery’s $(document).ready function and it also has an issue with saving via ajax in CakePHP.

There’s a helpful page on the Bakery that outlines some issues you’ll run into trying to get CakePHP & Prototype working with TinyMCE but it’s a little out of date now (I’m using CakePHP 1.2RC1, TinyMCE 3.09 and jQuery 1.2.6 at the moment). I’ll go through examples that illustrate how I solved the two problems I ran in to but I’m not going to explain everything you need to do ajax submissions with CakePHP.
Read the rest of “Setting up TinyMCE with jQuery and CakePHP 1.2″…

CakePHP is a really nice MVC framework I’ve been using for a project I’m working on. I’ve been using one of the 1.2 betas for what seems like forever but I just now saw they’ve got a Release Candidate out as of a couple days ago. The MVC pattern fits a whole lot of applications or acts as glue for a lot of web apps where the main goals don’t fit MVC. I find that CakePHP is fantastic for getting a lot of the monotonous code out of your way so you can focus your efforts on the important stuff.

Here’s the release note. You can download it from the main page at CakePHP.org.

This framework has a few warts and like any young software, it will see API changes that break code. Don’t expect it to solve every problem for you but it will give you a huge boost to start-up speed on building new applications. In the long run you have to remember it’s a tool for you to build an application, not an application in and of itself.

It’s time for me to dive in now and start my upgrade, I hear some of the conditions on my find() calls will have to be fixed…

Here’s a quick tip for PHP error reporting and display in development.

When a project is in the early stages of development you want to see all the error information you can. You probably want E_STRICT on especially when you’re starting from scratch, to help avoid relying on deprecated behaviour. The E_STRICT flag is only available as of PHP 5 and is not included in E_ALL until PHP 5.2 (there’s a little disagreement on php.net between the definition of E_ALL in this table and the earlier note about error_reporting on the same page).

In an early development project you also don’t want to have to keep tailing log files to see the error messages. That’s a pretty sure way to miss errors. So you want to set the display_errors flag on. You also want to control this on a per-project basis, since some projects will have legacy bugs that you’re not fixing right now and those can be left spouting errors to logs until someday in the future when you decide to fix them.
Read the rest of “Displaying PHP Errors in Development”…

Getting an error code back when a Lua script dies is actually pretty straightforward. Use lua_pcall() or one of its relatives to call the script and the return value will tell if there’s been a run time error. Read the rest of “Catching Errors when your Lua Script doesn’t start”…

I wrote a program a little while ago that draws a Hilbert Curve. Really all I did was adapt the Java source code that’s on the Wikipedia page talking about the curve. That Java source used a class called SimpleGraphics that I’m not familiar with. I wanted to use SDL in C++ for my program. It was easy enough to convert the Java code to C++ but to do the drawing I decided to just implement a SimpleGraphics class in C++ that uses SDL to perform the actions that the program needs.

Since then I revived my interest in integrating scripting with C++ and pulled a Lua interpreter in to that project. Now my program loads a Lua script and executes it. The Lua script has access to the SimpleGraphics class that I wrote. Now that the script interpreter works and can call the drawing methods I decided to take the algorithm for drawing the Hilbert curve and implement that as a Lua script. It was actually pretty easy. The resulting source code works as a sort of Rosetta stone for the three languages.
Read the rest of “The Hilbert Curve in Java, Lua and C++”…

I glossed over the fact that my program crashed at the end of the script in my post on hooking up Lua to a C++ application. I new at the time I posted that there was a memory problem in calling the SimpleGraphics destructor but what I didn’t realize was that the problem was actually caused by the difference in the declaration of the SimpleGraphics class between the header file that the C++ program sees and the declaration that the SWIG-generated file sees. Here’s the one that gets compiled in to the C++ application: Read the rest of “Ooops - A SWIG Interface Correction”…

At level 69 you can use a Riding Crop to get a mounted speed bonus. Since my main is finally level 69 I’ve been eying the Auction House. I just lucked out and found one for only 41 gold. On my server they’re usually over 80 so I snapped it up right away. Of course then I have the issue of switching trinkets so can have the Riding Crop while mounted and go back to my other trinkets when I dismount. This got me looking at macros again and since macros are written with Lua in WoW, I thought this ties in nicely with the Lua interpreter stuff I’ve been writing about lately. Today I’ll share the macros I’ve been using for a while now to smooth the rough edges off the World of Warcraft interface. I didn’t write most of them but I’ve tweaked them to meet my needs.
Read the rest of “WoW: A few Lua Macros to save time and clicks”…