Matt_ptr *

OK, so I know I’ve been beaten this horse to a pulp. But today it reared its ugly head again.

The ORM in this case is phpActiveRecord. I had used this in other projects and had a generally positive experience, so I thought it would be a decent fit for this quick little user registration database I had to set up.

Of course, I had neglected to check whether or not phpActiveRecord worked with PostgreSQL. Silly me, when I looked at this page and saw ‘pgsql’ in a DSN, and when I read that PDO is used for the backend — which provides a decent API for the library to use — I assumed that I would be safe.

In short terms, no. In longer terms, fuck no.

There’s an error, apparently in all versions that I could find, in the pgsql adapter. I guess there were some attempts to fix it, but it remains uncommitted to the main branch, despite being a year old.

So good-bye to phpActiveRecord. It was fun, that one time when I used you and you worked correctly. You can now join the wall of shame with lack of PostgresQL support along with WordPress and Drupal. (Yes, I know Drupal core has at least partial support, but modules may not necessarily support pgsql — which could have been avoided with a decent ORM).

The saga continues… sigh…

I’ve always liked CherryPy. I thought its routing method was a very novel take on the application routing problem. But I never used it too much because it was too loosely coupled for my purposes at the time.

Fast forward to a few weeks ago when I hear about circuits.web, part of the circuits framework. Event driven, modeled after CherryPy, asynchronous, web-socket support, and loosely coupled — which I need this time.

I’ve spent the better part of three weeks working with circuits.web, and I can say it’s been a resounding disappointment.

First of all, documentation is non-existent. And when I say non-existent, I mean non-existent. The core circuits framework is poorly documented at best. The circuits.web component isn’t documented at all. The closest thing to documentation is a collection of asinine examples that have almost no merit for real life applications, if they even work at all.

Second, I can’t exactly tell if the project is still being worked on. When I first started, I naively looked at the dates on the recent commits to the whole circuits project. The circuits.web portion hasn’t been committed to since August. WebSockets were made a candidate recommendation in December. Nothing in circuit.web’s implementation needs to be changed? That makes me suspicious.

Lastly, the Component architecture seemed like a good idea, but it seems to be thrown together in no logical way. Case in point?

Components handle events. Controllers inherit from Components. Controllers can’t handle events. Or if they can, I couldn’t figure out a way. Who knows why — there’s no documentation.

I was trying to create an Authentication component for an admin controller. There are of course, no examples of this. The authentication examples — that is the ACL, HTTP Auth, and HTTP Auth using /etc/passwd — all use an authentication scheme that is site wide.

What I needed was a way to pick specific actions that would require authorization. I figured out a way by accident, and within 3 seconds found a way around it due to the “channel” member of the Controller.

The channel in circuits.web, I assume, specifies the routing for the dispatcher to find the object. So your Admin Controller object might have a channel of “/admin”. The problem I found, using a Component for forcing authentication, I could bypass the Auth Component by going to, “http://localhost/admin/“. Note the trailing slash.

Change the channel to “/admin/” or “admin” and get a 404 on all admin actions — but the auth component works.

And that’s where I’m at. I should have went with CherryPy on this project, but no, I guess I felt like being disappointed by Python web frameworks again.