revjim.net

I'm always more eager to contribute to making an existing product better than I am to create my own product. That's why, despite the large amount of code that Inklog has so far, I'm still making every attempt to consolidate my needs with the needs of another project.

BinaryCloud is a great project. It's full of top notch developers and implements a very intriguing method of development that, I suspect, would make web application development more robust, more featureful, and would provide the means of creating them much quicker. However, the Inklog model is not present in this project. At all. So this means that, much of the Inklog code would be put to use. It would have to be converted into the BinaryCloud way, but, once there, it would work. Unfortunately, aside from a few pieces of rendering code, most of what BinaryCloud does wont help Inklog in any way. There's probably enough code there that would be used to make it worth my while. However, there are also enough things that would need to be changed to their current system in order to provide the dynamics that I desire. And, in this case, I think bad sides outweigh the good. Again, the code is great, it's just not, in its current state, suited to the system I intend to build.

ezPublish is another system I'm considering. In more ways than I can count, ezPublish is Inklog. They've done a couple things differently than I would have. Some are better, some are just different. However, all in all, the system seems to have the right feature set that very little work would be required to get it to do what I wanted Inklog to do. So I dug in deep. Started building the new revjim.net in ezPublish. Unfortunately, some aspects of their code base are so screwy, it's hard to make heads or tails out of what's being done. While there is plenty of documentation on how to use the system, extending the system is mostly undocumented. Writing PHP scripts that use their API is even more undocumented. So, I'm left with a few scattered comments in 50 - 100 classes to try to determine how to do what. I encountered my first road bump — PHP scripts must be run from within the ezPublish install directory — within hours. It took 10 hours to figure out what was wrong. After I did… I was going again. I hit the next road bump — Certain portions of the classes run as user "anonymous" even when using the API and, therefore, "anonymous" must have certain permissions to get things done via PHP scripts — that next day. After about 8 hours of debugging someone in the forums responded to my request for help, and that eventually led to me finding the answer I was looking for. Now, I'm at another road block — some types of content cannot be browsed. If a browse is attempted, PHP throws a nasty error — and I just don't know if it's worth crawling through thousands of classes to determine. Even if I did get past it, I already know of one other thing — the proper method for placing data into a content object with a field of a non-standard datatype — that is causing problems and, I'll eventually have to figure that out too. Even if I did figure that out, there are enough things about the code I have now that bother me that I am certain I am not using the classes correctly. So, when the next release comes out, something I'm relying on will most likely stop working because I'm not doing it right.

I looked at Plone, briefly, but it just seems weird. And the installation requirements are steep enough that many users may be unable to install it at all.

So, it looks like I'm back to rolling my own, and I hate that. It's not all futile though. In looking at these codebases, I've learned a few things that I should do, and many other things that I shouldn't do. So, at least I'm learning something.