Forum OpenACS Q&A: Re: Extensibility in OpenACS - Six Architecture Options

Collapse
Posted by Frank Bergmann on
Hi,

thanks for the qualified feedback. Very interesting, Gustaf is proposing a fifth architecture option with OO Tcl, and we have forgotten to mention a sixth option by customizing only specific modules and creating different, customized versions of them. And AMS in fact already contains a lot of the stuff that we were looking for.

However, there are only three replies to this subject until now which probably means that there aren't many people/companies suffering from the "extensibility issue". Let's face it...

"Customize Code and Refactor" against "Copy-Past-Modify": That's in deed an interesting point. However, refacturing seems difficult if you are working in a project-by-project base. It's considerably cheaper to start from scratch again, compared to refacturing the not always clean customizations from the last project. Arch may definitely be able to improve this. Maybe there is a way to propagate changes in the trunk (let's say an upgrade from OpenACS 5.1.1 to 5.1.2) to all of the branches. Very interesting idea. Implement extensibility by means of a version control system. Sounds strange, but it may actually work in certain organizations, particular if they are suffering from strong time/resource pressure...

Briefly describe of all the known per-customer customizations

A very helpful and straight-forward recomendation. We'll try. Do you know of a better tool to do this apart from "diff"?

Concerning OO TCL: It's a very interesting idea, proven, and could basicly be seen as a way to "patch" your code a posteriori and as an alternative to "user exits" (yes, that's SAP speak I guess. They are successful, though...). Did somebody use this in the OpenACS context before? I personally had to go through piles of obscure OO code in several large projects, and inheritance just doesn't seem to work when there are many different developers patching the code during several years of the lifecycle of an application. Maybe it's not the fault of OO though, but of the freedom that OO gives to users...

I would be very happy to receive more feedback from other users/companies whoface the extensibilty problem. I know that there are atleast the following companies:

- Competitiveness.com (Spain)
- Quest (Ireland)
- Project/Open (Spain)

Thanks a lot!
Frank

I am working toward more of a 'code generation' option, which I think presents a variation not mentioned here. In short, you use a specification language to generate the data model and forms - there are some examples of similar things out there, including for the web - ERW http://erw.dsi.unimi.it/ , written in Java which produces PHP code, and Xdobry, written in TCL which produces forms on an X windows box.

I think there are enough intermediate APIs to make our acs-objects and CR, search, etc available as tcl scripts generated from a schema definition (well, we're getting there).

The extensibility would then arise by adding custom data elements to the schema def, and re-running the generator.