How it worked out May 5, 2008

Well, I went through, and found out that I was, while it wasn’t too hard to implement, going to be reinventing the wheel too much with lightbox2 . I found that it has been painful, however, to add lightbox to the site. A rather large 200 Kb footprint… not so easy on me since I’m already loading a lot with spry (Spry data is hefty. It makes up for it with the complete and total cleanliness, but still… ickypoo!). I’m going to rebalance the load on the server by throwing up some thumbnailers and eventually I’ll get to a level at which I can make the page also gracefully degrade from JS for all you textual/cellphone browsin’ peeps. Later, if I feel masochistic, I’ll put in some code for AIR and the like so that you can load it on an iphone. It totally won’t be worth it for now, however. And ack… what a pain. The added size in JS files. Does prototype HAVE to be so big?

I tried using lytebox, but no beans. It simply chokes on the SPRY, is what I’m thinking is happening. Otherwise, I could cut out a lot of the excess. :-/

I’ll go into aptana and try to debug lytebox later (it’s still on the server), and see what I come up with. It probably won’t be pretty… but it would be worth it just to reduce the script overhead.

Yet another terrible idea in AJAX May 3, 2008

So, I’ve been reading a lot more now and have started goofing off with mootools and mochikit. And yet, I fall back to spry. And so now I’ve got this ludicrous scheme of js include juggling to try out.

Spry is awful good at filling in data.

MooTools has compact effects.

Mochikit pwns the DOM.

But. I need all three features… I need to handle xml data rapidly and compactly (there’s a lot of data! tightly nestled in dense xml to save on transfer time), I need effects that aren’t going to kill CPU’s or require lots of includes, and I need to chuck DOM modifications out as I change the focus of the web application. :-/

It was nearly doable to put mootools into Spry and throw around some DOM hacks, but as I’ve been going through it, I have to agree… this is becoming a ton of unmaintainable code. Something that reeks of ‘google google google’ and when I did, Mochikit seems like a great solution. But, ah. That’s the crux. Should I get script crazy? Ick. Right now, I’m more or less loving mootools, but the mochikit is the straw to break the camel’s back. Either way, I’ll get back to this blog on the progress of my projects if I decide to go through with it. As you can guess already, the RSH hack simply didn’t work out. It’s for… I’m not sure… something like google mail or something the like. Otherwise, I’m just better off doing my own cheap URL anchor hacks by my own wit. I can’t bash anyone for using RSH, but it’s a pain if you don’t need the whole thing, as far as I can tell.

If I were to splurge and put everything I wanted on the page, it’d probably be about 500k of code, and about 24 k of content. :-/

So, back to chunking solutions into the air in the hopes that I find a quick fix for various things.
In the end, I’ll hopefully have a good looking comic browser of sorts for my site. You know… with chapters, page turns, searchability, and xml fetchery fu (if I see another comic that has buttons that just change a single image by reloading the whole page… again… I’ll cry). Keywords might have to wait.

DOM and me (and our marriage counselor, Aptana Studio) May 3, 2008

A budding relationship. By budding, I mean I need to send flowers and pray there isn’t a shotgun wedding. Herein lies my tales (so far) of taking a server I have no control over, and turning it into a ‘half’ AJAX web-service. I’ve been recently messing with the DOM, and besides having half of what the w3c says going straight over my head, I’ve been making progress. Sorry… let me rephrase that:

Hacking the DOM is like begging for ie and ff2 errors and bugs. To be honest, it’s deadly and you should be very careful with it. For now, let me just say that *cough*hugemegaGHEYadvert*cough* I’ve been loving Aptana studio. It has an immediate listing next to each crazy DOM feature, listing compatibilities and warning you about which things will fail vs which will succeed on various browsers. And it’s been a lot easier and fluid than dreamweaver, which I guess has somehow… gotten too clunky? Well, either way, it’s now been made much more viable to hack at the DOM with Aptana telling you why some of that stuff is scary. If you can combine this with a decent knowledge of how to build coherent conditionals (those awful ” ? : ” blocks are what I’m talking about), and you’ve got a very good way to crush these problems as you hack away. Plug in the debugger, watch the pretty activity meters and funky console output color your page, maybe enter a few commands to make sure things are straight. Now go back, hack some more, put in conditionals, do the debug runs, rinse, lather, peanut butter, repeat. (I also recommend coffee to avoid segmentation faults)

So, I need to really review Aptana more harshly on this, however, because this process is centrally two-fold… hack first, but then you need to debug and test what you do. But the debugger is hard on the browser. I mean, it’s not all just a bunch of farting rainbows and happiness… but take a moment to enjoy that dream for a moment. Lil’ more. Kay? Great.

Okay, so here’s some beef with this system. I’ve been messing with Aptana on macOSX for a good bit now too (about two days. Yes… two days. … Stop laughing. I’m serious!). While I’m a total novice at AJAX and DOM hackery fu, I’ve noticed some consistent bugs (meaning: easy to get around, but annoying) when it comes to using firebug in tandem with Aptana’s debugger. Firefox just loves to choke. So, when you’re busy hacking this stuff up, I definitely suggest that you also try using a pseudo setup of Spry’s debugger (pretty easy to include… it has a frustrating interface, but it works rather swell for things) and the firebug debugger. The reason is that I’ve found re-loading and restarting the debugger has become… paaainful for firefox to endure. The best bet for your money is to use aptana to code up some junk, do a quick debug run, then do finetuning and tweaking and anything that might be just a bunch of mostly stable, small changes with the spry debugger or another onpage debugger. This seems to really keep things finely greased and unflinching. Of course, you sacrifice the debugging features from Aptana… but then, their debugger really fails at small tweaks, and even firebug, I’ve found, tends to bloat a little and slowly screech things up a bit. Borking is normal debugging order, but I’ve found that an on-page javascript debugger seems to really cut down to brass tax much faster when you don’t need too much sophistication.

Otherwise, this Aptana studio fellow has been really brilliant and a great spinoff of the Eclipse IDE format, which I’ve thoroughly enjoyed *cough*moreBIAS*cough* but that still doesn’t make it foolproof for what I’ve been doing. I can’t quite square away what could be making firefox so unstable. I don’t hear a lot of other people getting the same issues (yet… maybe I’m looking in all the wrong places), so I suggest that you play around and see if you don’t get the same issues. If only it worked on safari, I could definitely nail it down. I have a few more extensions to check out and see if they’re causing problems, but otherwise, a whole ‘restart’ of firefox every other debug run has been my only major complaint.

….

and of course, I haven’t really tried anything else with Aptana other than Spry. Every time I start a new test project… I already heartily thumb away on google, sifting the pages about all the other free AJAX libraries… and I think I’ll start seeing if the debugging goes smoother with them.

This is a really lousy review, and hardly touches upon Aptana… but then, I don’t have time to go through and just talk about everything. I think it’s better that way… let other people talk about it more.

Thoughts? Angers? Icecream? Maybe you thought this was about marriage and started to wonder what country I’m from and which Babel fish server I used to cough this page up? Comment and hopefully I’ll be around to mod/add anything spam karma wants to be touchy about.