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

Dedicated site for JForms

Today I’m launching a dedicated website for my GSoC Project “JForms” support , I’ll be publishing news and documentation of the component there, also there’s a forum for support questions and similar stuff.

Screencast of my GSoC Project

My project for GSoC 2008 was to create a WYSIWYG forms component (Web form editor) that runs on Joomla! 1.5 , This video shows a simple usage scenario ( including an encounter with a bug! )

Links:

Development trunk(SVN): http://joomlacode.org/svn/gsoc2008/JForms/trunk/

JForms blog on J! Developer website

Latest packaged version

P.S : I used CamStudio to create this video.

I Passed!

It’s been almost 5 month since my proposal for GSoC was accepted, I’ve learned alot in these concentrated 5 months about Mootools and J! 1.5 , I was introduced to many interesting people, Coping with College and GSoC was a bit challenging specially that I have classes during summer but things worked out well.

Final evaluation results has been announced a few hours ago, and I passed! , Which means I’ll be getting *The* T-shirt and the certificate Insha’Allah , Yaaay!

hmmm.. that’s all, I’ll go get some sleep :)

Web-based WYSIWYG Form designer

A few days ago I decided to suppress my “conservative” stance towards massive Javascript usage and started working on a WYSIWYG editor for HTML Forms, The application resembles drag-and-drop GUI editors, I’ve spent lot of time in building the codebase to make it as Object oriented as possible.

The codebase is simply composed of two parts, Core and pluginis “Elements”

Each draggable element is handled by a 2 files

• A javascript file that does the rendering and the event handling “Events are triggered by the core and passed down to each individual element”.
• A php file that defines what properties the element has, these information are used by the core to generate property page, this file is just meant to hold configuration parameters, no actual coding involved.

Adding a new element would just require writing two files and the core handles the rest.

I’m using Prototype, script.aculo.us and Webtoolkit context menu, No true AJAX has been used so far, everything is done on the client side.

Now the question is , what does the end user see?

• Drag and drop environment
• Context menu for each element
• Properties for each element
• Simple keyboard interaction “Selected element can be deleted by pressing the (del) button (except textfield and textarea)”

I’ve tested this on FF2 and IE6.

What I really need to implement right now is the “Resize” function

Why don’t you check A demo of the code in action

I plan to turn this into a Joomla! forms component soon Insh’Allah.

Update: My Proposal to Google Summer of Code has been accepted and I’ll be working on implementing this form editor as a Joomla! 1.5 component, You can find more information about my progress on my GSoC blog