Edit This Page 2.0 OpenACS Package Development Plan

Dave Bauer Last updated 2004-05-21

Sorry, ETP-2 will never be, unless someone jumps in to build it. I have moved on to using the content repository more fully, and ETP does not make that easy. Too many places make it difficult to change ETP. One option may be to deliver ETP content with another CMS at some point. This is quite possible, ETP templates could be imported into and managed by the CR.

This is a preliminary plan to update the OpenACS package edit-this-page to offer a richer content management application while moving it towards using more built in content-repository features. Along the way it will also result in work on adding such features as dynamic form generation based on object_types.

Currently edit-this-page fills a need for a simple way to add pages in a hierachal structure to an OpenACS site. It is difficult to extend ETP in a way that conforms to accepted OpenACS conventions. It recreates much of the built in functionality of the content-repository. In taking advantage of the current services OpenACS offers, this project should be able to identify area of OpenACS that need improvement, especially in the area of content management.

The plan is broken into several steps. Currently I have four phases. Each phase should be completable in a short period of time, generally less than one month. The goal is to drive development of a CMS solution for OpenACS. I am basing this work on the edit-this-page package because it is already in use in several sites, and I hope to offer an upgrade path for the existing users. In addition I am going to look into the work done by Jun Yamog on his BCDS and BCMS packages to see where code and concepts can be shared. Both Jun and myself believe that a CMS framework can be developed that allows various CMS type applications to be built on top of by adding user interface elements. By enabling rapid advance of development we should be able to reach the critical point in Pind's Rule of Five and realize what parts a content management system built on OpenACS really needs.

Phase 1

Convert all UI forms to use ad_form/form builder
Allow editing of all default attibutes on one form. This will make it easy to create most content items. Worry about dynamic form geneartaion for additional attributes later.
Make sure all content_type attributes are registered in acs_attributes for built in and custom content types (define requirement in the documentation, I can't see how to register the attributes automatically)
Use content::get_content to get content instead of rolling our own and/or use CR views to query for content.
Allow file-upload of HTML content to get around browser form limitations
Allow file-upload of images, word docs etc. Store in filesystem. Use cr_item mapping table to associate files with content. (In future version add support for a media storage facility, for now, just "attach" uploads to the item. Possibly use a simplified attachments package for now)
Test using cr_item_child mapping table to define sort order for items in folders instead of the acs_object tree sortkey
Improve susbsite support, add general comments support via parameter, add notifications support on folders and pages.

Phase 2

Use CR content_type/content_item/context to assign templates. This will allow assignment of templates by application/content-type, etp package instance (folder), or idividually assign a template to one page (content_item)
At this point we should be able to allow multiple content types per folder. Right now ETP support 3 types for each folder anyway, the application type, symlink, and extlink. So its just a matter of offering the UI to add a content type. The existence of the UI can be parameterized.
Store templates in the CR for versioning, publish to the filesystem for rendering, or store to custom CR storage location. (possibly defer to later phase depending on progress). This works along with assigning templates using built in CR functions.

Phase 3

Allow creation or extension of new content types through web interface. Requires dynamic form generation.(Jeff Davis is working on this)
Support static publishing of finished HTML pages or partially rendered dynamic adps. (this is already in CR), at this point the content type template will be merged with the content and pblished as an ADP which may contain a master reference as well includes. We won't have any other tcl setup I don't think. Any variables filled from content attributes should already be rendered at this point.
Support custom ADP tags to get used by content editors and template editors to provide easier access to includable templates.

Phase 4

Add default workflow, with tcl api support for customized workflows with possibility of a web UI.
Add support for the new categories package.

Besides these items, at some point Oracle support will be added back in.

Please comment at the forum thread.