Forum OpenACS Development: Re: How OpenACS coding could get its groove back

Collapse
Posted by Dave Bauer on
Replying to my own message:

Here are some problems ACS 4/OpenACS are supposed to solve:

From the kernel requirements documentation https://openacs.org/doc/openacs-4/object-system-requirements.html :

"A major goal in OpenACS 4 is to unify and normalize many of the core services of the system into a coherent common data model and API. In the past, these services were provided to applications in an ad-hoc and irregular fashion."

"A major goal in OpenACS 4 is to unify and normalize many of the core services of the system into a coherent common data model and API. In the past, these services were provided to applications in an ad-hoc and irregular fashion.""

So one goal is to increase code reuse and reduce ad-hom implementation of general services in every package.

And this:

"The OpenACS 4 Object Model must address five high-level requirements that repeatedly exhibit themselves in the context of existing services in OpenACS 3.x, as described below.

Object Identifiers for General Services

Support for Unified Access Control

Extensible Data Models

Modifiable Data Models

Generic Relations

"

I didn't want to copy the entire document in here. Go ahead and read that, and then we can decide how we are meeting these goals and if we agree they are still important.

I think they all still are important. Most of the 5 features are not well used besides object identified and unified access control.

---

One the ability to use a SQL query anywhere you want, you can still do that if you must. One of the criticisms of OpenACS 4.x is that it is too hard to get started. It has been suggested that having to learn pl/sql, in addition to tcl is one barrier to entry. By keeping most of the queries in tcl procs, we can simply the learning curve. This has to be balanced against performance of course. A tcl proc can still return mutiple rows from a query, so we don't need to do a seperate query for each row. The query inside a tcl proc should do whatever joins are necessary to return all the information just as efficiently as if you had embedded the query inside your tcl page.