Forum OpenACS Q&A: Working notes on OpenACS 6 proposals

I converted it to plain text and posted it at http://zmbh.com/oacs/

We have a lot of existing functionality that has been poorly exploited, but there seems to be widespread misunderstanding of what functionality actually exists.

Just one example:

Feature: Architecture improvements
Skinny-storage

You can add new attributes to any object via the UI.

This isn't an architecture improvement, the object attribute SQL API allows for the addition of new attributes to any object. Has all along. Works fine. Tastes great.

So at most this is a UI improvement. However, beyond that, the CMS UI allows for the addition of new attributes for any objects that happen to be content objects. You may recall we've already approved a TIP for 5.2 to merge content object and "plain" object attributes code, to make the SQL and Tcl API and underlying datamodel the same. Doing so will mean that the attribute addition UI will work for objects of all kinds - though still buried without refactoring in a damned unobvious place, our abandoned CMS.

I noticed a good ten or twelve other examples in the proposals, out of perhaps a couple dozen proposals.

I guess my feeling is that you can't properly discuss where you'd like to go in the future without an accurate assessment of where you are today. Basic navigational concept :)

* I like the point about configuration versus customization, and like the goal of moving towards configuration rather than customization.

* I also like the idea of incremental implementation. Yes, let's do this gradually.

Can I propose an extention to the notes use case:

People can be assigned to notes. Any number of people can be assigned to a note.

Multiple notes can be edited at a time (scalable interface). I can edit three notes on one page.

The reason I add these to the use case, is that I think one of the problems with ad_form is it doesn't address these cases very well. Using multiples is very hard to do in my experience. Multiple dates, for example, is rather nightmarish.

I'm also thinking about the data soup idea in relation to the most recent application I've developed: project-manager (I'll be releasing version 1.0 this week or next week, by the way. We're using it now at my workplace. Yes, we finally upgraded from ACS to OpenACS!).

So I can see the advantage of being able to put all sorts of objects in my projects and tasks. It would be nice to be able to put blogs and pictures and files and so on inside a Project or Task. I'm not so clear on how the system will know how to display everything.

I've read all the data soup articles, but I guess I'm "core hacker" enough to get how it will work.

(Note: the XML was too small for me to read, by the way).

Among other things this will help us measure the amount of work required, where we'll need to concern ourselves with backwards compatibility, stuff like that.

Now, we want additional dimensions so we can arrange the site in different ways just by moving folders around on a tree.  Do we do this with entire additional dimensions, or with symlinks, or is there a need for both?  I can see use cases for each.  For the first, I want to build one site map for visitors, another for customers, and a third for staff.  I could do that with permissions masks, but that only lets me hide sections, not change their layout.  For the second, Tom's example of putting a photo in two places is a use case.  In that example, the photo should still have only one "true" home, from which permissions are determined.

Anyway, my vision of how these columns work, which I've held for a long time now ...

1. context_id

   This should actually disappear as it's only used as something to hang a trigger onto for permissions, and it shouldn't be overloaded as a stand-in for the physical parent_id pointer. I won't go into details here other than to say that making it disappear would force programmers to use the API to change it, it would get rid of two columns in objects (security_inherit_p), and the API could forbid errors like trying to tell the system to not inherit permissions but to also inherit them from object FOO (we have to support this now due to the overloading by several packages of context_id as the physical parent_id). I think, but am not sure, that we might see improved performance (not much, just a little) during object creation.

2. parent_id

   The physical parent of the object, the addition to acs_objects perhaps having been TIP'd already, perhaps not. Existing packages either overload context_id, package_id, or add a parent_id (content repository) so upgrade scripts would have to be written to take this into account. Fairly large job, worth doing IMO.

3. package_id

   I've always looked at this as being primarily a convenience for the package author for those times when you want to find all the objects created by a package. For instance when you delete a package instance or when you uninstall a package systemwide. These scripts have historically been buggy and hard to write. Folks have overloaded package_id to make up for the lack of a physical parent field (i.e. notes) - historically their own private package_id but now carried into acs_objects - and, once a proper parent_id is added, this should be Strictly Forbidden :)