Forum OpenACS Development: Re: XoTCL interface for Objects (aka. extending methods for objects)

There has also been package builder which allowed you to define the objects along with their attributes and it created automatically a package with create, access, edit and list functionality, so you could quickly start a new package by defininig it's objects.

So, yes, I do agree, it is a pitty that we only have the functionality which deals with content items and not with objects per se, but this is how it is. You still have to write you custom insert statements, you custom add/edit/delete procedures, pretty much what package builder and query writer (if I read you correctly) have been trying to automate for you.

< future >The beauty of generic classes for acs-objects is that you can define the class definition of you own acs-object type, and, as it is inheriting from the generic object class, it will automatically provide you with the methods for add edit delete without you having to write them (just define the class). It also deals with additional attributes (inserting into the appropriate tables as given for the object type) and allows you to access the attributes anytime you like (set my_object [$object_type instantiate $object_id]; set myvalue [$myobject set myvalue]) . Additionally none of your old select queries will break as the new API is using the same information as stored in acs_objects, acs_object_types, acs_attributes and custom object tables. So you can easily create the class and get the information how to do it out of the acs_object_type table and improve the readability of your code (also by getting rid of your custom procedures for add/edit/new, which, remarkably, are not following the naming convention in all packages). Done using [$myobject save]. < /future >

Okay, so much for the blurb once we get the functionality written. And take this only as an idea / guideline. It is very crude and comes from the top of my head. Also, as this is a project for 5.5 (not 5.4), maybe we should not invest too much energy into it right now but focus on the summer release with bug-tracker enhancements, site-node improvements and, my personal favourite, new e-mail handling.

I've been working on a vastly simplified class/object data model. Probably one of the most fundamental concepts used to simplify programming is to use abstractions and avoid special cases as distinct building blocks. As an example, a number of the base tables in OpenACS are not object tables, so code which deals with them are special. In my model, I have an object table, a class table and a mapping table (and optionally an object extension table). Classes are objects, and every object has a class. (Object 1 is of class 'class', it is self referential). The maps are not objects, several fields are used as the primary key. This simple model supports versioning, tagging, multiple hierarchies per object, archiving, logging, etc. These features can be applied after the fact, or removed. You can join objects in new ways without changing the class models. You can attach any object to any other object, so it would be easy to add a comment class and use it with every other object class.

Anyway, I just had a thought, more for myself I'm sure, but until now I was thinking how incompatible this model is with OpenACS, in other words, what would be the point of creating an OpenACS package with this datamodel. But maybe I could reverse things a bit and make a few changes to OpenACS so that everything sits on top of this model. Probably not too much code would be required to add a 'create object' function for the acs_objects table, which would get its id from my object table. Then I could use my system to create objects distinct from OpenACS, but still use the features when necessary.

The XoTCL code would have an easy time with this datamodel, as the whole point is to leverage generic methods for reuse. Of course, the same will be true for Tcl and pl code...