Forum OpenACS Development: acs_atributes usage ?

this may be a dumb question, but i have not figured out how the
attributes i define on object_types that i create, are used in
openacs.

for example i created a learning resources collection type, subtyped
it with an exam resources collection type and created tables for
both. of course i also created attributes (eg. points,
allowed_time, ... ) for the object types. but what does openacs do
with this information ? does it provide special services for
manipulating attibutes ?

or is it the openacs way to mantle an update query on a single column
of an object with a "set_attribute function" for its object_type?

can someone point me to a really good example of what these
attributes can be used for ?

tia, peter

There are in essence two types of attributes that are supported, those that are stored in your type's custom table and those stored in acs_attributes.  The reason for the latter is to allow for attributes that can have multiple values.

The first type are almost uniformly set by explicit updates on the table within the toolkit rather than set by the slower "set_attribute" method (if you change more than one attribute, the latter approach will result in multiple updates, *slow*).

So  you can think of the attributes stuff serving a descriptive rather than functional purpose for attributes of that type. As Jon mentions, they make possible  the auto-generation of forms by the templating engine and similar things. We might want to explore this in the future.

The second type - attributes that can have multiple values and are stored in the attribute values table - is hardly used, and that's just as well IMO.  The only way to set such an attribute or get values is through the attributes API.

I haven't had time to go through all this in exhaustive detail, but for our second development/release cycle I've been thinking we might want to get rid of the second type of attribute altogether and maintain the first type strictly for descriptive purposes, i.e. to give a db-independent way to autogenerate forms and the like.

I think it makes sense to use the RDBMS as an RDBMS rather than to try to totally hide it in an abstract object-attribute model.  If the entire toolkit lived within the object-attribute model it would be substantially slower (which is probably why various aD implementors used UPDATE directly in their code for attributes stored in the type's custom table).

I was thinking of its use in the static datamodel, not for the dynamic extension.  But one could provide a generalized facility based on "alter table" (which is what 3.x user group types do).

The "alter table" approach doesn't work for multi-valued attributes, of course, unless you added enough weirdly-named columns to support the maximum number of values or abandoned standard SQL features entirely (i.e. use PG arrays).

So I guess a more accurate statement would be that we could get rid of the attribute values table if we did not support multi-valued attributes.  Perhaps it wouldn't be worth it ... as I said I haven't looked into this in great detail yet.

The rapid protyotype package (#2) I picked up off the arsDigita site. It works ok but the code it generates requires some hand editing to work. Again not a big deal it just needs some work.

By #3 I mean you need to be able to create an object that consists of other objects. For example a contact could be a person, address and phone number. So in the system I'm working on you create an object called Contact and give it 3 attributes Person, Address and Phone Number. The datatypes are person, address and phone_number. You might set max_n_values like person 1, address 3 phone 5. That way one person can have 3 address and 5 phone numbers.

I've integrated this into the templating system by creating a function that can display an input form for any object type. It's formating is simple so an addres might look like

line 1 _____
line 2 _____
City _____
State _____
ZIP _____

Line 1 ______
Line 2 ______
City _____, State __ ZIP _____

Finally there is a function that can take an ns_set of objects and puts them in the database based on the information in the attribute table. It can handle insert and update but currently not delete.

This is all based on the forms part of the templating package which appears to have a lot of functionality but it not well documented.

As for #5 I marked it optional because it's not needed for everyone. In my case it's just as likely the site is accessed by another program and currently the interface of choice appears to be XML.

As far as getting into the base system with the exception of the XML part there is very little code, however for it to be truly useful many base objects might need custom "widgets". The XML part might be more difficult. It's written in PL/SQL and very oracle dependent.

Also I've been thinking about making acs_object_types and acs_attributes acs_objects so I can use the permission system on them. In the above example if I add an approved attribute to the table I could use the permission system to show that attribute to the "content manager" and not the person writting the article.

A by product of this would be the ability to create and manage acs_object_types form a web interface just like any other object.

Personally I think it's valuable to have the metadata available - for instance there's code in the content management system to automatically generate forms, do revision inserts, map widgets to types (to serve as defaults) or attributes (to override the default), etc.  The CMS UI is painful but the use of attributes isn't, though it would be nice to be able to describe attributes at a high level rather than painfully define them once in Oracle PL/SQL then Postgres PL/pgSQL.

Bottom line, then, is that the metadata has been used by aD in the past to provide for automatic content management of arbitrary content types and that we should make more use of metadata and work harder to support rapid development.

However the CMS carries its own attributes and other baggage due to its history as a standalone product but that's another issue.

So in my world I'd ditch the attributes values table, multiple valued columns (though we might be able to map those into Oracle and PG arrays in the type table since both offer some support), automatic initialization of attributes by the object creation routine (SQL's "default" works quite well for real columns in real tables), etc.  I'd  view the attributes mechanism as a provider of metadata in order to speed development, rather than a mechanism to implement a true object-attribute system.

As you can see from the thread here, there are those in the community who really like the full object-attribute model.  My view is by no means a consensus view.

I think it would be very cool if OACS had a generic facility for creating search/edit/add/delete forms for any object type.  As well as the ability to add/delete attributes for these object types.  Perhaps even allow the creation of subtypes from an existing parent type.

As a potential application of this, imagine being able to add attributes to the "user" type and having these attributes automagically appear in the site registration and user profile forms.  This might also greatly simplify the creation of new packages as well as allow for super-fast prototyping.

I poked around a bit, and it seems that we have bits and pieces of this in the OACS currently (ie, attribute::* for managing attributes, attribute::add_form_elements in particular for generating dynamic forms, define_function_args, ETP has its own attribute manager, etc.).  But overall this API and acs_attributes in general seems to be sparingly used.

Barry: you had a lot of great ideas in this thread.  You also mentioned that you might release your code.  Any news?

Would this be an worthwhile goal for the upcoming 5.0 release?

Yes that will be great.  Maybe you can show the stuff you did  some time ago?  Also Tom Jackson I think is doing something similar with his Form builder I think.

Ded's classifieds package does something similar too.  Maybe its time to have a standard.

I guess.  It looked real good from a developer's eyes.  Since we aren't able to use it, it does prove our opinion that its a nifty developer idea with little real world application.

Still I think it would be nice.  Maybe if the app will write code?  Instead of a system/package that does things from you.  You basically use it to create some form of template or framework for you.  Like converting what you have done to a admin writer package.  The code should be bare minimum so the developer will only have to add, not add and subtract code.

So an admin package that runs on a particular engine looks nifty, but a admin package that writes bare code using OACS standard code may have good use?

Barry, it sounds like we are working different ends of the same problem. I haven't been that interested in solving the form generation problem, since I seem to always have a lot of fields that should not be available to any/all users. But you can check out my query-writer package. It is due for an upgrade, where I will make a few data model changes and scrap most of the admin ui (I think). I am planning on changing the tcl api so that procs named qw_* will be renamed to qw::*, but the url api will remain unchanged.

The biggest change will be that you should be able to create the pl code for the package with one tcl call, giving the name of the table to base the object on. I already have the function to go through pg and find all attributes, back to acs_objects that would apply to the object. Further api calls could add/subtract/modify the default pl code generation. Another big change will be that a lot of pl code will be replaced to use regular dml code. Updates can use a little pl (an is_object_p function) plus mostly dml, deletes might involve more pl. But updates are the big problem, being very inefficient in pl, where each attribute is updated separately, and then you need a separate function to nullify, or reset an attribute value.

The query-writer also works for non acs_objects as well.

Check out the trace function for attributes here.

I'm also experimenting with a table specification/generation idea that uses a language similar to xml, but far simplified. I figure having a db neutral method of table specification could speed up and regularize table code writing. I like having named constraints for every column constraint, and it is a lot faster do this automatically.