Symphonious

It seems every time I do some work integrating EditLive! I find a new technique that makes it easier, simpler and more future proof. It's not so much inventing new patterns as finding creative ways to apply them.

For instance, tonight I wanted to get the upload manager in WordPress working with my EditLive! WordPress plugin. There's a whole bunch of logic and implementation detail in the JavaScript that WordPress outputs and it expects the editor to be TinyMCE. Fortunately, earlier on the plugin had drugged TinyMCE, taken it out back and shot it1, so it wasn't available. Fortunately, it's pretty straight forward to create an adapter for the TinyMCE runtime api that works with EditLive! and drop it in by assigning it to window.tinyMCE. Simple stuff and very similar to techniques I've used in other situations, but extremely powerful and easy to not think of. In fact, I'd tied into the autosave by manipulating JavaScript classes and all that became redundant now that I have the TinyMCE adapter.

This kind of thing has to be my favorite feature of dynamic languages - they make it so easy to mess with stuff and subvert the authors original intent.

1 - that's a surprisingly accurate description of the lengths you have to go to if you want to change the editor in WordPress and still have the "Use Visual Editor" preference work as users would expect.↩

Just for my sanity, before an OutOfMemoryError is thrown, the garbage collector should do everything it can to free up more memory right? What I'm seeing now is that the JVM does a partial GC, throws an OutOfMemoryError and then decides to actually do a full GC which frees up enough RAM to get things working again.

Very annoying and I'm not sure what I can do about it. There are definitely no remaining references, but I still can't get that memory back.