Bear in mind that different mentoring organizations have different requirements for their proposals , this should be your #1 priority, but almost every organization will require you to have a list of deliverable and a plan with timeline.

These proposal were both submitted to Joomla! in GSoC 2008 and 2009 and were accepted

Both documents are under CC Attribution (Just mention the source in references)
GSoC 2009 Proposal (PDF)
GSoC 2008 Proposal (Plain Text)

Hope this helps someone.

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

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 thought about Version control systems (CVS/SVN) but they are not very “user-friendly”, Wikis was another option that offered many needed features like

• A good degree of user friendliness.
• Multi-user ready.
• Revisions.

But I needed a way to automatically import translation files “php files in Joomla!”, so I wrote this solution.

The current wiki system is based on DokuWiki offers the following features

• Automatic import system that breaks down large files into smaller fragments “50 line” each to allow more users to work on one file simultaneously, The system also reconstructs the file from these fragments when the user requests to download the file.
  
• Utilization of iconv to provide translated files in various encodings “Arabic for example has two popular encodings, “UTF-8 and Windows-1256″”.
  
• A status system that calculates the progress made in translation of any given file that is present on the wiki.
  
• Ability to export translation files into PO format, this feature might prove useful for translation revisers.

We’re using this Wiki for organization of Arabic translation, View a sample of the translation wiki here.

I still need to do some more modifications to the Wiki before it’s ready to be released for public.

Update September 4th, 2007: I’ve released the code on SourceForge you can access it by checking out the CVS there.
The project url: http://sourceforge.net/projects/arabic-tcpdf

CVS Checkout command

It is a known fact that Joomla! 1.0.x can export content into pdf format, however, this feature doesn’t seem to be working well when used to export Arabic content to pdf format, either windows-1256 or UTF-8 encoded.

To address this issue, The guys at the Joomla! core has moved to TCPDF library to export pdf files, this library has support for images and more importantly UTF-8 which means it can -theoritaclly speaking- be used to handle pretty much ANY langauge, This is true for many Left-To-Right languages, however, For a Right-To-Left language like Arabic the situation is quite different I’ll try to brief the problem here.

First off, Arabic is a complex script language, This means that putting letters side by side is not just enough, A typical Arabic letter has different combining forms based on its context in the word.
For a PDF generator to handle Arabic text correctly it must pre-process the input text and determine which combining form to render “Shaping” ,otherwise the text will appear as separated Arabic letters as shown in the following image, So far Joomla! 1.5 PDF engine doesn’t take that in consideration which means any Arabic text exported by Joomla! will appear as separated letters.

To tackle this issue I’m using a class called ArGlyphs by Khaled Al-Shamaa.

Quoting from the project description on phpclasses.org

The class takes as input Arabic text encoded using Windows-1256 character set and performs Arabic glyph joining to output a string encoded using UTF-8.

So basically this class will fix this shaping problem , I had to modify it a bit to accept UTF-8 without messing it up, I used the phpUTF8 library which is bundled with Joomla! 1.5

Now the output looks like this

Which brings us to the second problem,The TCPDF Library only outputs text from Left-To-Right which causes RTL scripts to be displayed in reversed order, simply reversing the string before passing it to the rendering engine won’t fix this problem, I think FriBidi may fix this but it is not available with every php Installation so I can’t relay on it to fix this problem for Joomla! ,So I gave it a shot and written my own code (I always like to write my own code ;P), The code I wrote simply breaks down text into pieces based on its UTF-8 range and then reverses the pieces “runs” that are identified as RTL “like Arabic” and leaves other runs without modification.

Letters are correctly shaped “with minor errors” and are rendered right to left, however, the lines are reversed , you should be able to read it correctly by starting from the bottom line and proceed upwards,I’m yet to fix this problem , If you have any suggestions on how to fix this or an easier way of doing the whole thing please let me know, I think there gotta be a better way of doing this.

Edit ( 8/5/2007 ) : I have managed to fix that issue but the code still needs to much clean-up and bug-proofing , here’s a sample of the output.