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…

I’ve always thought growing grass was a terrible idea. As a kid I was pretty practical and I didn’t see any benefit to having a green lawn full. I was also pretty well aware of the amount of effort required to maintain the lawn at home growing up since the mower was often my job. I hated mowing it and my parents weren’t even really big lawn freaks. We had weeds and dandelions and bare patches. I always marveled at the crazy amount of time and effort our neighbours across the street wasted on keeping their yard green and presentable.

Now I’ve grown up and I feel pretty much the same way. It might not make my neighbours happy but at least I didn’t follow through with my plan to pave it and paint it green. As a child I assumed the problem was that people wanted a large green square in front of their homes and concrete seemed to be a very practical solution to that problem.
Read the rest of “How to not grow creeping charlie”…

Getting together a good development environment for PHP websites isn’t that hard any more. On a Windows machine, I recommend a pretty simple approach. Install Xampp, install Eclipse PDT, install XDebug. For bonus points set up Subversion and get TortiseSVN (or, I guess, whatever other version control works for you).

I’ll give a quick rundown here on how I set up a development environment on a Windows machine, I tested it as I was writing it and I don’t think it took but 2 hours. Read the rest of “A Complete LAMP Development Environment - Xampp, Eclipse PDT and XDebug”…

The SVG Open is shaping up fast. The call for papers has been out there for a while now but if you’re quick you can still present a paper or run a workshop but the deadline to submit for papers and courses is April 18 and that’ll be here before you know it. The SVG Open is the conference for people doing SVG. The SVG Open has been running since at least 2002 and seems to get a little broader appeal every year it runs. Look at the broad areas to cover: client-side Javascript toolkits, map overlays like Google’s, widgets in Opera, cell phones and other embedded applications, UI elements in Gnome and KDE, desktop tools like Inkscape. Those are just off the top of my head, that kind of a list just didn’t exist 5 years ago - not for mainstream applications like these. SVG is growing in adoption and I don’t see that slowing down anytime soon.

I’ve been out of the scene for a while but things have really come a long way all of a sudden. There’s some great support across the latest browsers - compare that half-green Firefox 3 to the qualified “about half of the tests passed that test features supported by Firefox” from a few years ago. There are solid, supported tools that make SVG creation accessible to anyone. Inkscape may only consider their release 0.46 less than a 1.0 but it’s a real practical tool that’s adding features in leaps and bounds. Want some graphics to work with? The Open Clip Art Library has piles of subjects covered.

There are more and more compelling reasons to choose SVG every day. If you’re someone who’s been applying SVG already then share what you know and go present it at the Open.

Google I/O looks like it’s right up my alley. I was surprised to see Steve Souders is presenting there. He’s the author of YSlow and Yahoo! was printing his 14 tips for speeding up website front-end performance on cards for Blogher last year (under the unusual title of “How to be a Better Binary Babe”). I have used YSlow to improve my own sites’ performance though I definitely don’t get an A on all of them yet. I’d love to hear what else he has to say on the subject.

I also see there’s one on Caja, another attempt to make Javascript “Safe”. While my first reaction to this and Douglas Crockford’s Adsafe is to roll my eyes, I know I’m going to hear a lot more about both soon so it’s best to dive in and find out what’s what. Really, I think the whole AJAX and Javascript topic is the most interesting part to me right now.

Jeff and I started tossing around the idea of making a trip out to I/O a few days ago. It doesn’t look like a real possibility but I saw that registration is open this morning so if any generous reader wants to contribute to sending me then drop me a line and we can talk .

On Pavlov.net talking about some improvements in memory handling on Firefox 3:

It isn’t reasonable to expect all those authors to write code to manually break the cycles themselves.

This reminded me immediately of an MSDN article that took a decidedly different stance on pretty much the same problem in Internet Explorer:

The good news is that memory leak patterns can be easily spotted if you know what to look for.

The fact that the MSDN article is from 2005 really drives home just how stunned I was when I first read it. The page goes on to describe how web developers should analyze their Javascript and write their code to work around bugs in garbage collection. I understand the idea that sometimes users have to work around bugs in a program but that’s definitely not the message I got looking at the MSDN article. It read a lot more to me like “we sent out IE 6 SP2 about a year ago and we have no intentions on fixing this any time soon.”

Then look at the audiences that these two very different standpoints are aimed at. The Mozilla post is about extension developers, a relatively small and advanced group compared to the number of web developers - the ones most likely to understand the issue if anyone does. The MSDN post talks to “every web developer” and says to “Use defensive coding practices and assume that you’ll need to clean up all your own memory.” While this may be practical advice for advanced coders, in this context it says to me that there’s no intention from Microsoft to really fix this problem.

Kudos to Mozilla for working to improve efficiency and close leaks instead of blaming web developers.