Forum OpenACS Development: Re: FYI: My Vision and priorities for OpenACS - UPDATED

Good ideas:

• Removing title/context bar from the tcl script, it either needs to be in a database, or constructed on the adp side. Not sure if it works or not, but when you use the property tag, is that variable then available elsewhere on the same page (like using the set command?) If so, any text 'created' in the tcl script via a set command should be replaced by a property tag.
• Doing away with special hierarchies hard coded in to various tables: like package_id. This one I consider especially bad as it makes a display function (package) owner of data...not good. Everywhere package_id has crept into core models will need to be fixed for this removal to work. However, all hierarchies are special purpose, and if you don't need set of semantics, the trend it to utilize an already existing hierarchy with new semantics. Thus we have the parent_id, context_id confusion. What is needed to handle this once and for all is to create a special table (acs_object_structure), which creates a series of hierarchies. By simply adding a tag to a mapping you can use one table and one set of (tree_sortkey/connect by) functions to maintain things. This will end the confusion, and allow users to create hierarchies without the overhead of building all the maintainance functions needed. For mapping objects to packages:

  acs_object_structure__create(:parent_obj, child_obj, :tag);
  

• Objects should be handled more generally. My Big complaint with the CR/CMS is it is too removed from acs_objects. All the basic functions of CR should just apply to any object. Objects are all data anyway. How you display the data is a different story, and many folks will disagree on how it should be done. If there were more similarities between object types and content types a lot of things would be much easier. For instance, what if we had a message type object which just contained fields for title and body. The same message type could be used for forum messages, email messages and blog messages. The difference would be that you would map the message to different containers using acs_object_structure. You could easily create composite structures as well. For instance a web page could be composed of a series of messages, photos and other html fragments (each being objects themselves). However this composition would still need a method of arranging the data: a templating language which would specify what parts of the object to display, which subset to display, and in what arrangement....