Forum OpenACS Development: Making use of the content repository easier - building a Tcl API

I close to writing a TIP on this but thought I'd start a discussion first.

Jun has written a somewhat comprehensive Tcl API to much of the CR functionality. It's in contrib now. Several of us have talked about adding it to the CR proper, and in fact Collaboraid is using it in their simulation package (also in contrib).

I've just put in a few hours playing with extending that even further, to make possible the creation of content types from Tcl in a straightforward, declarative manner. The APM supports "before-install" callbacks which means you can create content types from Tcl before any SQL (which might define procs and functions which refer to the type) gets executed.

ISTM that this is an easier way to generate content types, as it gets rid of the need to laboriously call PL/[pg]SQL functions for each DB.

I'd like to Jun's stuff rewritten to fit in the CR proper (means mostly getting rid of the "bcms" namespace, though the bcms can continue to use the old code until Jun has time to rewrite it). And I'd like comments on the declarative "create type from spec" approach, to see what folks think about it.

so ... discuss!

Here's an example of creating a content type from Tcl, suitable for inclusion in a before-install callback (why not do this for regular objects? Yes, we should, one step at a time, though ...). Note that this creates the attribute metadata (a step often ignored by our crew because it's so laborious) as well as the actual table and columns, which means the CR's autoform generation features and INSERT views can be used with the new type ...

content_type::create -spec {
    content_type bar
    pretty_name bar
    pretty_plural bars
    table_name bars
    id_column bar_id
    supertype content_revision
    attributes {
        {row1 {
            pretty_name Row1
            datatype integer
            column_spec integer
            default_value 0}}
        {row2 {
            pretty_name Row2
            datatype text
            default_value row2_value}}
    }
}

I think having this in a standardized way in TCL helps a lot.

Furthermore it would help us with writing a quick M$ Access like frontend within OpenACS (you just define the content type with it's attributes and OpenACS offers you templated/list-builded create,view,edit,search pages that store the content in the CR with all the benefits involved).

This would make it easier for the occasional user to quickly create a database for his stamp collection and make use of all the great features OpenACS has to offer.

Last but not least, TCL is easier than prozedural database language and should lower the barrier for using the content repository considerably.

Dave, I'm hoping to have time to work on BCMS API migration in March (after I get back from Guatemala) but if you have time to get started, sure, go for it.  We do want consistency and we don't have to maintain compatibility with Jun's work if there are incompatibilities we'd like to fix, etc, since his contrib package will still be around in contrib.

Jun, I want to look into the generic object create as well but probably won't share code between the two because there are still too many difference, particularly in the area of attributes.

Maybe you, Dave and I can work together in March on migrating your API stuff to the CR proper?  I'm also interested in making it much easier to use the autoform generation stuff in the CMS (which needs moving to the CR) ... it's time to make use of the CR easy ...

Yes, I would like to look into integrating both normal objects and CR objects with autoform generation.  And of course you and Dave should continue to whack away at CR Tcl API stuff.

Thus far in the extremely minimal work I've done I've been mirrring the CR's structure, i.e. along with content_type::create I've added Tcl surrogate calls to the SQL create_type package functions content_type::create_type and content_type::create_attribute.

I think it would be a good idea to mirror the Tcl API namespace and proc names in this manner because we already have a bunch of code using the CR SQL defs directly that may never get re-written.  Using the same naming scheme should make it easier for programmers to switch back-and-forth from the low-level SQL calls to the higher-level Tcl API calls when working on different (older and newer, rewritten or not) packages.

Also ... I wrote my sample content_type::create proc using package_exec_plsql (which I added to HEAD a few weeks ago), which avoids the need for explicit SQL calls.  We should do this in the CR Tcl API for those functions which create things (SELECTs should be inline for efficiency reasons).  This really simplifies things ...

I just started looking at the CR and this seems like a really good idea. I've also been running Oracle and I'm thinking about switching some sites to Postgres;. It would be nice to be able to create most database structures in a database independent way. It also seems like object_type::create could be added with basically the same structure. Then you could create tables without writing two create table statements and you get object_types and attributes for free.