GSoC 2009

My proposal for Google Summer of code 2009 has been accepted, I’ll be working for Joomla! this summer , My project will be “Workflow extension” for Joomla! 1.6

I’ll try to describe what I’m trying to accomplish to get as much feedback as possible before starting.

The workflow extension I’ll be working on will support the core content component and have the capacity to support other components.

Document workflow will be broken down into a set of “stations” ,An item will be passed from one station to another in a particular order until reaching its final station after which an arbitrary operation will be preformed “e.g. Publish article”.

Structure

Core:

MVC based, the core will act as a central controller for the whole extension, it is composed of two parts:
1. A conventional component
2. Core plugin: A system plugin that captures J! Triggers related to content saving and passes them down to “Component handlers” (See below)

Hook Handlers:

Hooks will be implemented to allow developers to perform arbitrary actions when certain events occur, initially one hook will be implemented, this hook will be invoked upon transition from one station to the next.

Field Handlers:

They handle the rendering and storage of the “station” fields (e.g. comment fields, file attachments, etc…)

Component Handlers:

All component specific code will be placed here, these handlers act as a layer between the extension and the component whose content is being workflowed (e.g. com_content),

Each handler is composed of 2 files
1. An XML file that contains Meta data about the handler and a other parameters, among which is the “onSaveItem trigger name” which defines the name of the “J! Event” that is triggered when an item of the handler type is saved. (E.g. onAfterSave in com_content), the file also contains a list of supported “Final Actions”, which are the actions that can be taken when the item reaches its final destination (e.g. publish, delete, archive, etc…)

2. A php file containing implementation of the handler, it must implement the following methods ( Subject to change as needed )
• lockElement (id)
• unlockElement (id, gid)
• onItemEdit ()
• getItemRevision(id, rev)
More on getItemRevision()

If the component in question (e.g. com_content) does support version control, the method returns the requested version, if it doesn’t, then the method simply ignores the $rev parameter and returns whatever stored in the DB.

The above list of methods is a preliminary list and is subject to change as development progresses
When the workflow is saved, the component’s onSaveItem trigger is registered with core plugin so that when the event is triggered the core plugin captures it and loads the correct component handler.

Version Control:

When working with workflows content is likely to be edited several times before reaching its final form, which raises the question of “versioning” , This extension will NOT handle version control of content elements that are being workflowed but will have internal support for version control should it be included in future versions of the content management.
This internal support will be provided through “component handler” plugins which allows each component to have its own way of dealing with version control if it supports it, and to ignore it if it doesn’t support it.

Work scenario

The Administrator wants to create a new workflow for publishing content in a particular set of categories.

The Administrator will use a backend screen to create that workflow; he can specify the categories/sections he wants to be workflowed.

The Administrator defines the “stations” and the custom fields for each station and saves the workflow.

User xyz posted an article, the onAfterSave event is triggered, the core plugin captures this event and loads the component handler that corresponds to the content type (com_content handler in this case)

The component handler for “com_content” locks the article for all groups of users and unlocks it for the ACL group of station 2.

In the process of transition between two stations, A hook is invoked, calling all registered handlers, One of these handlers will send an E-mail to station users about the item that waits processing.

Station 2 user logs into J! And accesses the “pending items” view (Accessible via frontend or backend), station 2 fills the custom fields assigned to the station (comment and file attachment) and passes the article up to station 3.

The core locks the article for everybody except station 3, the article proceeds in similar manner until it reaches its final destination where the “final action” will be decided, supported final actions will be “component handler” dependent, for com_content, I cannot think of anything aside from “publish, delete, move to category/section”.

A word about the “views”

The component will have several views, but nothing out of the ordinary,except for the view that allows the administrator to create the workflow, This view will feature some javascript magic to increase usability, I’ll borrow some code from JForms :) .