About

So, page rendering is working, and it’s hooked up to Jack fairly cleanly. I fixed some character encoding issues, and then set about fixing some of the form components. While in there, I felt like it probably would have been a better idea to rewrite them all from scratch rather than port them over, since they’re some of the oldest parts of the original system and are all pretty hokey. Too late now, I guess… maybe for version 2.0. Anyway, I fixed up some issues with populating form elements with set values bound in from components, and also a bug in the generation of the action of the form, but it’s kosher now. It’s actually pretty weird that it’s working as well as it is; it’s strange for me to see the whole rendering chain working in a totally different language than I originally wrote it in 10 years ago. Next up: have to get the sessions working (at least in part) in order to get the whole “rewinding” system to work; that’s the internal mechanism that allows pages to know about previous requests, and how to respond to them.

Yes! First page rendered to a browser! I finally got some time to connect the Womble request-response handling to Jack using a very thin wrapper around Jack’s request and response objects. It’s super super rough right now, and slow, and there are tons of bugs, but it’s sort of working. I have loads of cleanup to do, but it’s nice to see it generate pages through an arbitrary JSGI app. I also added some better exceptions, which are just responses in their own right; when one is thrown, it can be returned as-is, and the system will convert it into a Jack response and render it.

Lots of problems still, charset seems messed up, Form is not generating the write URLs for submission, etc. But it’s coming along!

Urgh, haven’t had much time to work on this, but today I was able to throw an hour or so at it, and made some major leaps in terms of getting the component rendering working. I worked on it earlier this month and was able to get hack up a rough system that loads templates from inside bundles; it checks a few different places for templates and loads the first match. Today I was able to find and fix some bugs in the rendering, mostly to do with regex matching in the renderer. There are still lots of soft spots that I ported straight from Perl without really stopping to think how they’d work in Objective-J (or plain JS), so I am working through those bit by bit.

I haven’t been idle… just forgot to update this. I’m currently cleaning up a lot of the component resolution stuff. The lack of namespaces in objj has really thrown a spanner (a wrench for you Americans) into the works; I honestly didn’t really think about how much the Perl version relied on namespaces until I no longer had namespaces! Anyway, I’m also trying to Cocoa-fy some of it; using Cocoa-style Bundles to load resources, for example. A long way to go, but progress is progress.

OK, back in business. Finally got the rendering system puking out some content. The lack of namespacing in Objective-J is problematic; the perl version of the framework relied heavily on namespacing for creating structured hierarchies for your templates and components. I am still trying to resolve this discrepancy.

Damn, went and got married… that took up most of my July. I will be picking this project back up over the next few weeks. I have made some progress on the rendering/component system, although I’m wondering if I should have just written it from scratch instead of porting it. A lot of new tech has arisen in the last 9-10 years since I wrote the perl original.

Watch this space…

Yikes, World Cup has eaten up pretty much all my free time. Things will get back to normal soon. It’s given me some time to ponder a few questions that have come up during the port of this code from Perl; some things just aren’t relevant in obj-j and I need to figure out how to punt that stuff in favour of something simpler and more appropriate to the obj-j world.

Sorry lads, I have been sidetracked by the World Cup a bit… will do my best to keep ploughing on when I’m not doing my day job or watching WC games…

Managed a bit of work on the component rendering goop; mostly hooking up WMContext with the rendering phase and streamlining the code that allows rendering outside of the request-response loop. It’s not working yet because I need to make some decisions as to how to map URLs to components; in Perl it was easy, because the component hierarchy mapped directly to the component namespace. In obj-j, it’s not quite as simple since there is no namespace per se, only class names.

Got a few plane flights coming up, so hopefully I’ll be able to get some work done on this… at least as much as my battery will allow.

Right now I’m trying to figure out how to map the Womble WMRequest and WMResponse objects to their jsgi equivalents. I think to start off, I’ll port them and use them to wrap the jack Request and Response classes, and then gradually remove the layers of abstraction to use the lower levels ones more directly. I still prefer wrapping at least superficially, since the jack classes are pure JS, not objj.

Templating seems fairly healthy although I have yet to try it on a massive complicated template. There may be some reg-exp-related parsing issues to sort out, although things seem pretty stable. I’ve moved on to porting the WMContext and WMRequest classes, which are used during the request-response loop. Once those are in a vaguely working state, I should be able to start gluing it all together.

One thing that is still left un-ported is something called WMSiteClassifier. It’s a fairly involved class that represents a “lens” through which the application is viewed. The closest thing to it in common web parlance is a “skin”, although it’s a bit more sophisticated than just a skinning system; it also handles i18n issues, and has some fairly fun cascading resolution stuff that lets you “subclass” entire sites (so, for example, the ‘London’ version of your website could “subclass” your ‘UK’ version, and override only the functionality that it needs to make it more specific to London; the rest just cascades up the tree to the UK version. That will be the last major piece in the puzzle before we can launch a 0.1a.

Major progress on Template.j. I wrote lots of tests to make sure the template parser was working properly; surprisingly, it didn’t suffer too badly during porting and came out working pretty well. It seems fairly quick too; it doesn’t need to be fast though because it has a built-in caching system that caches parsed templates (if you turn it on). It’s useful for production; you can leave realtime parsing turned on in development, and then turn caching on in production for speed (and it makes a big difference). I have a few more tests to write, then I’ll be moving on to the big one: Component.j. I ported it, and it compiles, but it will need a lot of love to get it working. I’m not looking forward to it…

Managed to get Template.j to compile. This is another big step. There are still more classes to port but the hardest two are “done” now. Of course, they don’t work at all, and I’ll have to build up unit tests to get them working properly. But these are all moves in the right direction…

Whew, finally got Component.j to compile. Took forever to port this, but it’s a huge step. Note that at this point, it doesn’t work at all; still a long way to go before it’s working. But progress is progress.

Getting burned out on porting; the web part of the framework is big and old, making it hard to port; I’m stripping off some of the cruft as I go but it’s slow going, particularly because I have a Real Job™ that I actually have to do. I created an IRC channel on freenode, #womble if anyone is interested. I’ll leave myself in there, so feel free to say hi. Hope to make some more progress on porting later tonight.

Update: Made some major progress on porting the component system. Still lots of work to do, but things are moving.

I’m deep into the process of porting the big gnarly classes from the Web framework side of things; primarily this is the template engine (which is deliberately simple; there is only one new tag, “binding:”) and the way-too-monolithic WMComponent class. This stuff is pretty intense and the original code is approaching 10 years old. It’s stable and fast, so I’m hoping that it will be stable and fast once it’s ported to objj. The main problem with it is that it uses some fairly low-level perl goo, so porting that to objj is tricky. Perl was never designed to be ported to other languages (or, indeed, particularly readable…)

I don’t get a ton of time, but I’m definitely trying my best to get this into a state where people can try it out. The ultimate goal is to make the whole thing easily installable (using “tusk”) and have it just work transparently. I can imagine deploying apps written with it via AppEngine, for example.