Why a reluctant coder chooses “trashy looking” and “hard to use” OpenACS
This post is a continuation of a series on critical reviews by coders of OpenACS. And, what it means as a reluctant coder.
Review: looks like trash
Yes, the default style hasn’t won any awards. Changing a generic look is low priority for OpenACS developers. They expect you are going to change it when you deploy it.
For a reluctant coder, this is good news. They built a sturdy bridge, you just have to make the ramps on either side for those that use it.
There are other styles available as plugins (aka packages), and rolling your own is straightforward. The template system uses an onion layer approach that works well with css, html, xml and other nested tag markup languages. Templating is flexible. It keeps continuity of layers when modifying styles by including everything related to one layer in one context. Faster than having to change pages in bulk. By modifying css in one file, it can emulate ancient html3 embedded table styles or the latest responsive web design.
Review: hard to use
OpenACS is essentially a software library, request processor and scheduler on NaviServer. To scale well, design patterns for speed take precedence over code readability. These design patterns are part of the OpenACS programming style. Yet, it’s also expected that the code is the documentation when possible. Understanding the code patterns goes a long way to fully leverage the system.
Being able to contribute to OpenACS’ core code takes years of experience on the order of a computer science degree. The code is modifiable by a newbie. Yet contributing the changes to the core is difficult, because developers deploy the core in many different ways. Contributions from inexperienced developers (like myself) tend to break something for others.
You don’t need to know or change the inner workings of OpenACS’ core code to be able to get it to do what you want. I’ll explain more about making the system work for you in some other posts.
For a reluctant coder, know that developers contribute ready-to-use apps on OpenACS for some existing purpose where usage is intuitive in context of its original purpose. These apps may not be appropriate for other uses. Users and developers experience “hard to use” when trying to use something where it doesn’t fit well.