Forum OpenACS Q&A: some basic xotcl and ::xo::db questions

Hi all,

The xotcl acs object binding stuff is much nicer than I anticipated, i'm quite enjoying it!

I have three questions:

1. if I want to contain one object as a child of another, how do I efficiently do it. ie. if an object wants to contain a reference to a user, I can store a user_id in the object, then fetch the user based on that - but is there a more direct way to say that a slot is really an id that references another object instance?

2. similarly, is there a simple way to access multiples via parent references. eg. a user makes multiple forum posts, is there a way to say:

set forum_list [$user forum_posts]

based again on adding a slot with appropriate arguments? I can of course implement forum_posts quite easily with get_instances_from_db if not.

3. how do objects get destroyed normally? Do I need to destroy them myself, or will they be destroyed automatically at the end of the connection? Waiting for process exit is probably not ideal :)

That's it for now - I'm sure I'll have more questions later!

By the way, the best documentation I have found so far for the openacs/xotcl integration is the pdf by Gustaf and Stefan at http://alice.wu-wien.ac.at:8000/s5-xotcl-core-tutorial/ and of course the xotcl tutorial. Are there some other key documents I should be reading?

Collapse
Posted by Gustaf Neumann on
Somehow, you made me curious, what your expectation was. But anyhow, thank you for the flowers!

The only automatic bulk queries currently supported are to select a subset of the available objects. In these objects, references to other objects are just numeric IDs, which of course can be selected one-by-one (not the most efficient approach in many cases).

The problem is not to say "a slot is an id referencing some other object" (simple via subclassing), but the way how to say, what to do with the reference, in which cases should the reference resolved (transitively or not), and what to do with the referenced objects in general.

However, nothing hinders one to fetch the results of arbitrary SQL queries into a ordered_composite via "instantiate_objects" (see xowiki for several examples). In most situations, this leads to simple and efficient code. If used together with "::xo::db::sql select" then the code is as well portable (for most real world problems).

Concerning: "set forum_list [$user forum_posts]"
If you want to call a method of $user, $user has to have this method defined (normally, its class should have an instproc). If the method is defined it can either return the item-ids as tcl list, or it can be done in a way to return an ordered composite (e.g. via instantiate_objects)

Concerning: "how do objects get destroyed":
in general, XOTcl objects (and classes) can live the lifetime of the aolserver run in the blueprint (when created via -procs.tcl), or they can be created during e.g. a request. When an XOTcl object/class is created, and it is not supposed to live on, it has to be destroyed. xotcl-core offers the method "destroy_on_cleanup", which means that the object will be automatically destroyed when the request finishes (similar to global variables). If acs-objects are fetched via "get_instance_from_db", "new_persistent_object", "instantiate_objects", these are automatically marked to be destroyed automatically. These cover the most important cases.

I would as well recommend to add the xowiki tutorial
http://alice.wu-wien.ac.at:8000/s5-xowiki-tutorial/slides
to the reading list. The full library of xo* literature is at http://media.wu-wien.ac.at/publications.html

hope this answers your questions at least partially

Best regards,
-gustaf neumann

Collapse
Posted by Mark Aufflick on
Thanks for the answers Gustaf.

My expectation wasn't negative, I just hadn't realised how rich the openacs integration was, right down to creating the datamodels. Now if only it transparently handled data model upgrades like Malte was talking about ;)

I also didn't know about some of xotcl's features such as its meta-class implementation and design by contract support.

Collapse
Posted by Gustaf Neumann on
Dear Mark,

i am not sure, what Malte was talking about in detail (i have not looked into details about dynfields, i have no application that uses dynfields, for malte the situation is different in the po context). However, the b´db layer in xotcl-core layer has already some support for data model changes:

- In particular the xo-db-layer supports data model extensions, i.e. additional attributes or tables (if the extension is done via the object layer).

- The xo-db-layer does not support data model migrations (altering data types etc.). Here the problem is actually less the data model migration itself (one could drop the old data model and create a new one), but the data migration, where i have certain doubts that it is feasible to do it fully automatically. I am not sure, if i would trust such a mechanism.

-gustaf neumann

Collapse
Posted by Malte Sussdorff on
I can only second Gustaf's comment. The ::xo::db layer is great an works beautifully (XoDynfields is build upon that work). The missing pieces (although some only makes in context of dynfields):

- Extension tables: object_types can have extension tables in which attributes are stored. These are currently not supported by ::xo::db::*

- Support for multivalue

- Support for categories

- Attribute Elements (which are used to generate the form), taken from Dynfields

This is what XoDynfields has tackled, but if you need none of them or are fine with manually creating your forms, then off you go.

Also, if you want to use the website to extend your class then a proper user interface is missing (okay, im_dynfields provides that).