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

Collapse
Posted by Lars Pind on
I've thought some more, and have to agree with the amendments of Talli, Nima, and others.

In order for OpenACS to be successful for a variety of sites, including intranet, extranet, e-learning, project-management, social software sites, etc., the user experience must be completely customizable.

Hence, it should be possible to completely reorganize the user interface, the pages, of an OpenACS installation.

I'm currently prototyping this with Branimir. Here's what we have in mind:

The user interface consists of a number of "places" or "subsites". The subsite defines the master template, which in turn defines how navigation is rendered.

A place consists of a number of pages, organized into page folders for navigation.

A page consists of one or more "page elements" or include-templates, which are arranged on the page using a layout template (like the portal's 2-column layout, 3-column layout, etc.).

Navigation, including context bars, are automatically generated from the user interface specification, so that moving a page somewhere else, or changing its label (what the page is called in the navigation) will change it everywhere instantly - no more having to go through all the files to change the "set title ..." and "set context [list ...]" lines if you want to change a page title.

For example, in .LRN, "My Space" and each "Class" and "Community" would be places. The tabs in these portal-based pages would correspond to page folders. And the application pages would be fully integrated in this tab-based local navigation, so we avoid the confusion when you're on the "My  Calendar" tab of "My Space" versus inside the calendar application mounted at "My Space".

That's one dimension.

Another dimension is that for each page element or master template, the tcl/adp pairs of today, we need to separate it into 3 layers, with clear APIs between them:

- Script (TCL)
- Rendering (ADP)
- Stylesheet (CSS)

When placing a "page element" on a page, you can choose to override the ADP or the CSS or both, thus reusing the code, but completely changing the way that it looks.

In order to make this work with completely redefinable page flows, the "Script" part needs to have three types of API:

- Parameters: For example the package_id (except I want to replace package_id with parent_id, more below).

- Links: Since pages can be shuffled around at will, any outgoing links in the script part will have a corresponding parameter saying which page in the site map it will link to.

- Properties for rendering: Which variables are available to the template author.

Similarly, the template author should document which classes his template uses, so a CSS author can write a different stylesheet.

Another dimention is to unify our object system. All objects should have a parent_id, not package_id. Ideally, I'd do away with package_id altogether, as it only serves the purpose of acting as a 'container' of objects, and with parent_id, any object can be the container of other objects.

We also need to augment objects with title (including i18n) and with presentation_data (object-specific data, which a callback proc can use to render the object nicely, like Dirk has suggested before), and all the metadata that we need to present auto-generated forms and lists.

What this will do is give OpenACS a back-end, which you use to define objects and page flows, much like the old CMS package did. The front-end and the back-end will be separate user interfaces, which makes sense, because they will have different users - end users for the front-end vs. admins/developers for the back-end. It'll make OpenACS the "CMS for web applications" or "CMS for social software", depending on the VC hype of the day :)

Why all this? Because today if you want to have a user experience that's not a straight OpenACS out of the box user interface, then you'll have to fork the pages in the packages. And just changing the template for the pages wholesale is not going to be enough. Client sites need the flexibility to change the entire pageflow, and if they can do so while still making upgrades possible, everybody benefits.

So this will make .LRN a distribution of OpenACS, namely a collection of packages and specialized page flows, just like you'd expect it to be.

We'll try to make the prototype available as soon as possible. If nothing else, we'll demo it at the Copenhagen Bash on March 25-26. And we'll be writing some more detailed docs and putting together some diagrams to make it more clear. And then if other people agree on the direction, we should create a branch in OpenACS CVS tree to all work on this together.

/Lars

Collapse
Posted by Tom Jackson on

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....