Forum OpenACS Development: Re: Preliminary vision statement open for discussion

Collapse
7: Re: Preliminary vision statement open for discussion (response to 1)
Posted by Don Baccus on 03/16/03 06:29 PM
From the vision statement:
  • portal pages
  • a standard way to 'portletize' oacs applications
  • solid generic group management
  • a generalized version of the 'community'-thing in dotLRN
  • perhaps role-based access control
  • a way to define 'portal templates'
  • i8n support? (perhaps more oacs's task?)
None of the above items really fall under the dotWRK umbrella, IMO, nor indeed the dotLRN umbrella. Moving this functionality back into the OpenACS 4 codebase is one of our major goals for the rest of spring/early summer. In particular, the portals package, when the rewrite is completed, will provide our standard way to portletize OpenACS applications, the portlets it provides are simply templates, etc.

OpenACS already provides a solid generic group management facility - please study the groups and relational segments datamodels and supporting code. dotLRN provides a good working model for how a vertical application can use these tools. The problem in OpenACS per se is that there's not a practical UI for making use of these facilities in our subsite package. Lars Pind has the design of a new UI on his plate. My personal thinking has been to map role-based access control onto the group/relseg datamodel - the datamodel supports more sophistication than this but I think for a standard subsite package, role-based access control is something that's fairly easy to define a good UI for and is something that users will find fairly easy to understand. Packages or vertical apps needing more than this probably won't map to a generalizable solution that will make sense anyway, IMO, but since the datamodel is so general custom group management code is easy to to write.

The current OpenACS acs-subsite admin UI actually lets you do this (well, in 4.6.2 you'll be able to do this, since some of the bugs/quirks in the code have been fixed), it's just incomprehensible, that's all.

My recommendation is that the dotWRK folk concentrate on applications for the time being. Since the portal system simply maps templates to portlets, it's often possible to share template chunks between your portlet and non-portlet pages that provide views of data. So if you get the application right, generating portlets will be very simple in general. Maybe a day per portlet, something like that.

And on the application side I'd recommend concentrating first on the datamodel for the various pieces. How do we want to represent the various resources within an organization and how do we want to tie them together? I think the calendar package is a great example of what happens when too much effort is expended on writing code that provides pretty displays and far too little effort is spent on designing the datamodel.

Let's not repeat that mistake!

There's a lot of application code that needs writing before dotWRK can become a reality. By the time a dotWRK group makes significant progress in this direction I think you'll find that the issues in the bullet-list that heads my post will be solved in the general toolkit.

Of course, dotWRK will undoubtably want to layer custom UI on top of standard portal management and group management facilities that already exist, but that's a different issue ...