Forum OpenACS Development: Re: The future of OpenACS

Collapse
2: Re: The future of OpenACS (response to 1)
Posted by Tom Jackson on
There have to be very good reasons for changes like this, since not doing the change costs nothing, breaks nothing and supports everyone's current setup. This seems to be something advocates for change forget: focusing on the effort involved in changing the code. What about the inherent throwing away of all the effort that has gone into the current code?

LAMP exists, what would changes to OACS add to LAMP? If merely a me-too bullet point, it seems pointless, LAMP exists! Use it if it satisfies your customer's needs.

Refactor to xoTcl? For one I can say that I can never figure out what is going on in an xoTcl script. If the original code works, why would it need refactoring to xoTcl, why not refactor to Java or LAMP?

One thing OACS requires is a database. It is impossible to refactor OACS into modules which would work without a database. Also, remember that a lot of code is defined with ad_proc, etc., so moving code out of OACS is nearly impossible.

It is a short job to allow editing of templates via a web browser. The problem is more with supporting this as a core function, and then writing packages which use the feature.

One interesting point is that LAMP in most generic form simply means using the best tools at each layer, and keep code in the most applicable layer. Our layers are Tcl, AOLserver, AOLserver Modules, OACS-Core, OACS Packages.

So LAMP not so much a layered system as a code grouping and coordination system. The OACS system can push code groupings into different layers using general or specific API. This is more flexible that LAMP, but usually what you get with LAMP is an application which has to handle the whole process as a single bag of code. The OACS system allows for lots of reuse.

The fact that more specific tools are not used in OACS is really a matter of developer taste, which I have no interest in changing. I can say that I write packages which handle specific tasks so I can get lots of reuse and lots of separation of function. I've also written a package which allows lots of configuration/customization by design. Each content type can have a separate master, type, page and item template (or reuse an existing or default template). Each item can also have a different template. Templates are also content types, so they can have parameters and customizations: added and updated in the same way as other content.

All templates are editable via a web interface. My 14 year old edited her blog template by herself. The same installation has other applications, like an inventory/product list with ecommerce and photo galleries for each product. So it can be done, without any changes to OACS or interference from dotLRN. Just add data, configuration and templates, no Tcl coding, no database coding.