My GSoC Proposals

When I first applied to Google Summer of Code (GSoC) , I didn’t know how to write a proposal and what it should look like , I did some research here and there and managed to work something out , so I decided to put them online to help would-be GSoC students , My proposals are considerably long compared to other proposals I have seen online, also proposals are usually written with minimal formatting or even in plain text , no fancy formatting is required (Unless your mentoring organization mandates it)

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.

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.

It is finally here , Joomla! 1.5

The long waited Joomla! 1.5 has finally hit stable status

Wiki for group translation

Being active (just a bit :P) on Joomla! Arabic forum I’ve noticed the need for a mechanism that allows for “group” translation of extensions.

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.
(more…)

Arabic , PDF And Joomla!

Update August 2nd, 2007: I will be releasing this hack in the following few days Insha’Allah.

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.
(more…)