The Dopefly Tech Blog

<< The Dopefly Tech Blog Main page

Integrating 3rd party applications into yours, safely

posted under category: General on October 30, 2008 at 2:00 am by MrNate

Reuse-in-the-small is a solved problem. Reuse-in-the-large remains a mostly unsolved problem.
Jeff Atwood from Robert Glass, Facts and Fallacies of Software Engineering

I'm actively hacking at my latest toy project, which integrates a few 3rd party projects, and I had the thought, integrating a library, like jQuery, is drastically simpler than integrating a whole application, like a discussion board or WYSIWYG text editor. How do you solve these problems?

A few years ago I attempted to drop Ray Camden's Galleon Forums into another project. My app was Fusebox, so I had to rewire some of the front end, then move the component calls back out to the circuit. Sounds fairly easy, but with 3 gaping problems.
1st, the client calls and we have to modify it heavily. It turned out the only thing Ray's app was good for, was a starter kit on the database and DAO templates.
2nd, Ray puts out a new version with features we like, avatars, BBcode and signatures. We were so far out of sync that there's no way we could implement his new version.
3rd, I was never sure how stable the rewritten code was (turns out it was ok, but I was crossing my fingers).

Result: Thanks for the starter kit, now I'm on my own.

Fast-forward a few years to my new project, and I've started integrating Edit Area, a javascript code editor, into my application. Edit Area presents a few challenges, including the build program written in PHP and the authors not being native English speakers. Also, I have some application requirements, such as no externally linked files, and oh yeah, it has to work right (grrr).

So, how do I make changes to the application while keeping myself open to future versions?

The method I chose was to make changes to Edit Area in my build file. Ant calls Groovy. Groovy reads in their file and turns it into my file, which my program includes. It is repeatable but not destructive. When the next version comes out that fixes some of my problems (and I do hope it does), it will be mostly zero effort to update my code. Their changes could break my build temporarily, but I can tweak and adapt.

The biggest issue here is the challenge of meta-programming, or programming programs to reprogram programs. It's a lot of trial and error to get it right, and a lot of regular expressions. Also, Ant isn't exactly a real programming language, so I have Ant run a Groovy script. It's initial complexity to solve a repeating problem, which is a fair trade to me.

Result: Brainiacs only, but it works well.

Too old to comment!
On Oct 30, 2008 at 2:00 AM Adam Haskell (a.haskell via said:
Quick Question, if Fusebox had allowed for submitting to other files like other CFM pages would integrating Galleon been much easier?

On Oct 30, 2008 at 2:00 AM Nathan Strutz ( said:
That's a fascinating proposition. If Fusebox could submit to other pages, once you hit those other pages, you would be outside the scope of Fusebox, aside perhaps from an Application.cfc's pre and post events. That *sounds* like doing this would escape my security model, among other things. My problem is, I can't imagine it working.

I wonder if there could be a way to include a standalone app into fusebox with no model or controller... the links would have to be changed, but that could be automated.

Even still, Galleon had to be rebranded to fit my client. Honestly, if Galleon were built more MVC ready, that would make it much more easier to integrate. It is sort of my gripe against the way Ray made it, which probably works great for new CF'ers.
Too old to comment!