Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

pdcawley (485)

pdcawley
  (email not shown publicly)
http://www.bofh.org.uk/
AOL IM: pdcawley (Add Buddy, Send Message)

Journal of pdcawley (485)

Monday January 14, 2002
05:07 AM

OpenFrame refactoring

[ #2105 ]

If you've been reading acme or james's journals you'll know that they're responsible for Openframe, which is a reasonably lovely application framework.

The way openframe works is a little like the Apache request cycle but somewhat more freeform. Essentially you have a server that accepts requests, which are then dispatched to a pipeline of handlers ('slots' in openframe terminology), each handler declares (or has declared for it in the config file) a list of prerequisites and if they are matched, they get to play with the request object and can chuck responses and/or other objects back into the environment, or then can add more handlers onto the end of the pipeline.

Once processing falls off the end of the pipeline, any response gets output to the requestor.

This provides a remarkably flexible way of programming, and not just for web programming.

However, it's not as flexible as it could/should be, and it has a tendency to throw away useful data. For instance, instead of OpenFrame::Server::Apache generating an OpenFrame::Request::Apache (or maybe an OpenFrame::Request::HTTP), which conforms to the OpenFrame::AbstractRequest interface, it extracts most of the information from the apache request structure and generates an actual OpenFrame::AbstractRequest. And it appears that other bits of the framework depend on this fact.

The thing is, server specific request structures mean that if you know you're never going to repurpose your server, you can take advantage of the extra information or (more sensibly) you can then write request translators which take server specific requests and transform them into application specific requests (or simply into more generic requests).

Time to hack I think.

This leads me to a guideline for spotting potentially inflexible code:

Every time you see a classname used explicitly look at it very carefully, you may have an unnecessary dependency that's going to bite you later.

Hmm... this probably sounds a little more critical than it's meant to, but actually I think OpenFrame is really cool. Certainly it's the nicest perl application framework I've played with. Most of 'em scare me off be being either too restrictive or too wide open (I prefer the latter though). In general James and Leon seem to have got the balance about right. Check it out, you'll probably like it.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I know - I was thinking about all of this while I was on holiday, and came to roughly the same conclusion. The AbstractRequest is an interface -- refactoring along those lines fixes the problems that you've had. The biggest problem with that is with altering the slot system to deal with it. I've not seen the patches you've submitted so far, but I should be able to have a look at them tomorrow. Hopefully they solve the problem.

    As far as frameworks being a flexible way to solve a problem - its true. Th
    • Oh and you're right - OpenFrame is not just for web programming - that was another massive requirement for what I was trying to do with it - the web is just a protocol.