Some new PEAR channel code

Its been awhile since I've posted anything of any real consequence to the site, yeah, I know. Just been that kind of few weeks. In my spare time I've been playing with some changes to Davey Shafik's Crtx_PEAR_Channel_Frontend. The code's great and provides a good jumping off point, but I thought it needed some updates. Davey's been a busy guy and I had a few free hours every other evening or so for a few, so I decided to start extending it.

The first area I wanted to change was some of the text within the frontend. This was a problem since the Crtx version hard codes all of the display. I wanted it to be templated with the ability to provide a directory full of overrides so my custom versions could be used. As I started playing around with it, I found that most of the data I needed access to was only retrieved within the methods I needed to override to change the display. The method I started with, showPackage(), created the data structure for the package and displayed it all at the same time so I needed to break that out. The result was Model representations of all of the tables I needed.

With a few final hours today, I finished up the code and started packaging it when I realized I really had two packages; thus, Domain51_PEAR_Channel and Domain51_PEAR_Channel_Frontend were born.

Domain51_PEAR_Channel gives you access to the tables that the Chiara_PEAR_Server creates. Its still missing a few tables, but the basics are all there. I've also put together a pretty nice extension system too. Instead of just having "package_extras", you can define other objects that handle requests to certain properties, then those objects can go wherever they need to to handle retrieving them. My thought is to eventually extend this out to all of the objects. That would allow extending out developer's information, put more info on the channels, whatever. This will require some reworking of the Chiara_PEAR_Server UI in order to handle displaying of the fields, however.

The Frontend code is still very much a work in progress, but I'm throwing it out there to see what people think of it. Right now, it sort of cheats by extending Crtx_PEAR_Channel_Frontend to provide 99% of the functionality. In its current state, it only overrides showPackage(). No particular reason; that's just where I started. As time permits, it'll take on more and more of the responsibility from Crtx to the point that it doesn't need to extend it (hopefully).

Does anyone else find this useful, or am I the only one who plays around with their PEAR server trying to make it look pretty? :-)

One other thing, does anyone know why the releases.deps column is stored as a serialized array? I've got an email in to Greg on it, so hopefully I'll have an answer before too long, but in playing with the internals of the PEAR server that just seemed hackish to me. By not adding a releases_dependencies table, there's no way to determine what packages require any given package/version combination without some major voodoo regex'ing or grabbing every release, unserializing the deps column, and running through all of the dependencies looking to see if Some_Package was required anywhere.