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.
Re:Yeah...
james on 2002-01-20T22:48:59
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.
