It's me again :)

I'm here to announce the release of JForms 0.5 Beta and the launch of a new website dedicated to JForms support , The website is rather small but it'll grow , so , no more spamming developers website with JForms news :)

�

Changes in 0.5 Beta

Backend

• Design view
  • Plugins
    • Added "User Info" plugin
      When added to your form, this plugin will collect information about the user from Joomla! DB "Usertype, ID , Name, E-mail"
    • Added "Convert to" tool to convert from one type of element to another
  • A quick facelift
  • Usergroup permissions: this features allow the administrator to decide who can fill the form
• Records view
  • Filters:this features allows the administrator to choose which fields to display and also to perform a simple keyword search

Frontend

• Hardend the component against attacks.
• Added Router to enable SEF urls (Is it worth it?)
• Fixed several xHTML invalidities.

Download JForms 0.5

Looks like it, 2nd term is over , that felt much shorter than the first , anyway , I'll talk about what's been done in this term and what I'm hoping to achieve beyond GSoC 2008

Transition to mootools 1.2

That took some work to get done, I were adviced to move to mootool 1.2 since J! is upgrading to that version anyway, I also cleaned up the javascript code while I was at it.

A good question would be , Isn't the current version of Joomla! running 1.11? well , yes, and yes 1.11 is not compatible with 1.2 so you would expect the component not to work on the current version of J! "1.5.6 as of writing this".

The good news is , I managed to workaround this at the expense of a single non-fatal javascript error in the design view, The workaround simply unloads J!'s mootools 1.11 and loads 1.2, You shouldn't notice any difference while working with the component, unless you have debugging enabled on IE.

Simple HTML element

This one got me pulling out what's left of my hair (Which is few), I was trying to have an edit-in-place function with a WYSIWYG editor that allows the user to write HTML anywhere within the form much like he would in articles, but I'm afraid I failed at that for technical reasons I'm yet to discover, I settled for non-wysiwyg editor that accepts simple html and plain text, But I promise that this is NOT the end of it Insha'Allah.

Mailer function

Mailing in JForms is implemented as a "storage plugin", Currently it allows the administrator to decide if he wants to send form data to a particular E-mail or send "Submission confirmation message" to the user who fills the form , That's if the user specify's an E-mail in the form , The component has its way of knowing if that E-mail is acutally a user E-mail or not, I'll talk on that in the documentation, it would make more sense with pictures , Insha'Allah.

Localization support

Just went around to see if any string weren't enclosed in JText::_() calls , Wrote simple a language file so I think it should be easier to localize the component now

There's still about 5% of strings that aren't wrapped in JText::_() calls becuase they appears in independent files that are not loaded within Joomla! Context, but this issue will be looked upon as soon as possible.

Minor fixes and additions

Among the things that has been added to the component are:

• Pre-defined lists "Countries and US States for the time being".
• Multiple checkbox field.
• "onClick" javascript handler can be specified for "button" elements
• Ability to set default "Selected" values for all basic elements.

Countless fixes "But as always that doesn't mean we're bug-free yet :P"

What I would like to do beyond GSoC 2008

• Review, optimize and document the core of the component.
• Work on implementing missing features "e.g. Nested forms".
• Improve records view "allow search and easy manageability".
• Introduce a new plugin type "Export plugins" that will allow user to export stored records in various formats.
• Theming Engine.

Oh , You wanna see the latest version, ha?

Latest version JForms 0.5 Alpha

For those who might be wondering what's T minus zero :P

Greetings from Wikimania 2008 ( Alexandria ,Egypt ) XD

First I'd like to apologize for being too lazy on both the blog and the forge lately , I already met my milestones for the first term and some from the 2nd term "as per my proposal" so I took a break to keep up with my classes.

I'll try to brief what's been done so far with the component and what's left to be done.

What's been done

A working version of the component :) ..

I'll break it down to make it look like a "Big Deal" :P

In my opinion the most important part that's been done is the plugin loader/handler , it acts as a communication layer between the core of the component and the plugins "whether storage or element"

• Backend
  
  • The major part that took most of the time to design and implement is the workarea "The WYSIWYG view and the plugin-based model as a whole.
  • The Record view "The Grid!" , I used the a dhtmlx grid for the records' view, they have double license on that one, GNU/GPL for GPL'd applications and another license for commercial products
  • The "Menu element" , which would allow the user to add a form to any menu much like s/he would add content.
• Frontend

Much of the work done on the frontend relied upon the plugin loader/handler because most of the processing done for the frontend is done by the plugins "form rendering ,validation and storage"

What's to be done for the 2nd term

Mainly the 2nd term will be for bug suqashing and stabilization of the component , adding a few more element plugins and features "as time permits"

Here's a quick list of the things I intend to do in the during the 2nd term

1. Port the code to Mootools 1.2 (I'll need to study the difference between 1.1 and 1.2)
2. Implement the "html" form element, that would allow administrator to embed HTML within the form "e.g. add description of section in the form".
3. Study the feasability of implementing the nested forms feature.
4. Study the feasability of implementing a Themeing system.
5. Optimization, bug squashing and localization

I might've missed se stuff, but these things above are the most important at the moment.

Thanks for everyone who provided their feedback so far , greatly appreciated :)

Okay, This is exciting, After 2 month of work "yes I've started working before May 26th", It is finally here, a working version of the JForms component.

The component isn't yet stable/feature-complete/bug-free , but it has the most commonly used functions implemented, This version is an Alpha release and thus should never be used on production websites.

What features does it include?

You can read the previous posts to learn about the features, but there's one feature I didn't talk about , which is form vaildation, The component performs form validation on both client-side and server-side, you can test that feature by turning off Javascript.

How to get it?

I strongly recommend that you get the component by checking out the SVN, You can use the following installation package if you're not comfortable with SVN and would like to see where the project stands.

SVN:   http://joomlacode.org/svn/gsoc2008/JForms/trunk/
J! package   http://mosmar.com/com_jforms_0.2-Alpha_rev195.zip

I hope you like it.

If you encounter any bugs "very likely" , or if you have any suggestions , feedback, etc.. please let me know, I'll see if I can use the forge's bug tracker, but until then report anything here.

It has been ~15 days since I last blogged, These 2 weeks has been quite productive, In this post I'll talk about what has been done so far and what is left to be done till the end of the first term.

Ray "My Mentor" and I agreed that I should have a working component by the end of this term, everything should be working except for a few feature like "report view" which will be minimally implemented and will be enhanced during the 2nd term and the nested forms feature which will be implemented in the 2nd term

Backend

The backend is almost complete code-wise

What has been done

• The WYSIWYG Editor is almost complete ( 80% done )
• The Save/Delete/Publish/Add/Edit functions has been implemented.
• A plugin manager class that loads and triggers event on plugins.
• Database Storage Plugin implements the following events
  • onFormCreate
  • onFormEdit
  • onFormDelete
  Note: The component doesn't require any infromation about the Database , the table name or the name/type of the fields, They are determined automatically (Pretty much like JotForms , and even better :P )

What's left to be done

• Add an HTML element-plugin to allow the user to have HTML within the form "2nd term"
• Implement the Nested forms function "2nd term"
• Create the "report view"
  • A quick implementation by the end of the 1st term
  • Will be enhanced during the 2nd term
• Revisit the styles of the WYSIWYG area "low priority on the 2nd term"
• Form validation for the WYSIWYG Editor "2nd term"
• Other "TBD by the beginning of the 2nd term"

Frontend

The frontend has not been touched since the beginning of the project, It shouldn't be hard since most of the workhorse classes has been implmeneted during my work on the backend

What has been done

•  Workhorse classes "like the plugin manager" has been already implemented during my work on the backend
• The MVC framework is ready but not yet committed to SVN.

What's left to be done

Alot! But most of it will be done by the end of the 1st term Insha'Allah

• Extend element plugins to handle 2 tasks
  • Element Rendering.
  • Element Validation.
• Extend storage plugin to handle record insertion.
• Other "TBD by the beginning of the 2nd term".

You can checkout the code from the SVN using this URL "http://joomlacode.org/svn/gsoc2008/JForms/"

Thank you :)

A quick update

I've been working in the past few days on writing bare bones of the backend of my component, thanks to my mentor (Ray =) ) and MVC Guide I was able to do it.

For the backend I'm thinking

• 1 Controller
• 1 Model
• 3 Views
  
  • List view "The usual administration list, shows forms storerd in the database"
  • Design view "The magical WYSIWYG form editor :P"
  • Records view "Listing of stored records for any given form"

I've already committed the backend bare bones to the SVN.

Note : Ercan notified me that the backend entry point to my component shouldn't have the "admin" (unlike 1.0.x, thanks Ercan :)  )

A few words on the WYSIWYG Environment

The WSYIWYG Environment is simply composed of a workarea and a list of draggable form elements "Similar to JotForms"

Each element is loaded separately as a plugin, any plugin "element" is handled by two files:

A Javascript file

This file contains a class that inherits from a base javascript class "CElement" and overrides various method of the base class. "I'm using mootools for JS inheritance"

The WYSIWYG Environment triggers a set of events like "onDragStart, onDragEnd, onResizeStart,onResizeEnd, onUpdate,onDelete,etc.." and passes them to the concerned element , this element class is expected to handle these events.

An XML file

This file will contain meta information about the element like its name, description,storage requirements "Number and type of DB fields required per record", default width and height in the environment.

The wysiwyg environment will use the information in this XML file to automatically generate input fields and javascript code required to allow the administrator to alter properties of any element in the wysiwyg environment.

This is an example file that describes the "button" form element

<JFormPlugin type='element'>
<name>button</name>
<description></description>
<parameters>
    <param name="label" label="Label" control="textbox" default='Submit' valueType='string'></param>
    <param name="func" control="list" label="Type" default='Submit'>
        <option value='Submit'>Submit</option>
        <option value='Reset'>Reset</option>
    </param>
    <param name="ch" control="none" valueType='integer' default='15'></param>
    <param name="cw" control="none" valueType='integer' default='50'></param>
</parameters>
<storage></storage>
</JFormPlugin>

 The <param> tag defines properties of the element that can be altered in the WYSIWYG environment, here we have two properties, one is the label of the element "i.e the text written on the button" and the "Type" which has one of two values "Submit" or "Reset", it is clear that the button element doesn't have any storage requirements, Things will become more clearer when you see the code in action and play around with XML files. :)

 I'm almost done with the WYSIWYG environment , I just need to clean the code up and add a few comments here and there before I commit, that's too much for "A few words" , have a pleasent day :).

Before I start I'll set 2 definitons to make things clearer

I'll use the word "User" to refer the frontend visitor who will be filling the forms , and I'll be using the word "Administrator" to refer to the backend component user who is actually creating forms.

We're all set to start, For this post I'll talk briefly on a feature I plan to implement Insha'Allah, which I call "Nested forms" (Not sure if this feature has another name :P )

This feature will allow forms that support One-To-Many relationships ,i.e. Creating a form where the user can include more than one instance of another form into his form.

 For example consider the following form structure, This simple form asks the user  to fill basic personal data and recent jobs 

•  Name:
•  Date of birth:
•  Recent Jobs:
  •  Job I: 
    •  Position
    •  Start
    •  End 
  •  Job II:
    •  Position 
    •  Start
    •  End 
  •  Job III, Job IV ,  etc...
•  Attached Files

Each record can have multiple "Job" entries, The component will allow the user  to add as much "Job" enteries as he likes, for a live example similar to what I plan to implement see the "Education background" section in following link

https://www.google.com/jobs/application/application_student

To illiustrate my preliminary idea on how it should work from Administrator point of view I'll describe a simple usage scenario

For the aforementioned example ,The administrator will first create a simple form called "Job" having 3 fields (Position,Start,End) and saves this form.

The administrator then creates another form called "CV Form" and adds fields for the "name", "date of birth",etc , The administrator also adds a Special "Embed form" field , the administrator will be able to configure that embed form field to point to whatever form he would like to embed , In this case the administrator will want to embed the "Job" form.

Please note that I'm viewing the idea from the end-user (User or Administrator) point of view, I'll go into more in-depth technical details  on my plan for implementation (developer point of view) in later posts.

What you see in this post "and the one before" are just preliminary ideas, I'm widely open for suggestions, criticism, comments and hate letters :P

First off I’d like to thank everybody ,The Joomla! team for their confidence ,the blogs and everything ( Makes one feel important :P )

I'm really happy to see that the abstract article has received 7 thumbs up so far although it doesn't say much about the project :).

This is my first post here so I'll try to avoid going into the gory details, I'll just try to illustrate the rather brief abstract

The first thing I'd like to comment on is "Extensible, plugin-in based".

Now how does plugins fit into a Forms Component?

I'm currently proposing two types of plugins

1) Storage plugins

These plugins will handle the storage of records to various storage media "XML Files, XLS Files, Database, E-mail!, etc..", although I plan to implement only the database plugin "and a simple file system plugin if time permits" during GSoC, but this plugin-based design will allow 3rd party developers (3PDs) to store record information in whatever format they like.

2) Form element plugins

Simply put, these are the HTML form elements "select, input, radio, etc...”.

Now you must be wondering "why would these simple things be called plugins anyway?"

To answer this I'll need to go into details about the form design environment which will inevitably lead to lots of technical details but to brief things I just would like to allow 3PDs to create their own custom fields, like CAPTCHA elements, IP address entry fields, Date fields, etc..  , these fields doesn't behave like normal, innocent, everyday form element , they are not simply one tag, "a CAPTCHA  element ,for instance,  is at least an image + textbox", I want to build a framework that allows 3PDs to define "Custom form fields" and control everything part of their behavior

I started this post with the intention of making things more clear, but I think I just made them more ambiguous :P , anyway don't worry, I'll go over this part in full boring details in later posts Insha'Allah

That's it for "plug-in based", the next thing I'd like to comment on is "Single Screen form design".

When I first used a forms component on 1.0.x , I was kinda disappointed, I thought that I'll just need to go through a single screen to get the job done, but that didn't happen.

What I'm trying to do here is allow the user to configure all aspects of the form in a single, user-friendly screen and once the user clicks "Save form” that’s it, the form is all done.

I know you must be thinking "WYSIWYG" , well , although this single screen approach can be achieved without WYSIWYG but I think I'll go the WYSIWYG way, I'm still discussing with my Mentor , Mr. Ray :) , how far I can go with WYSIWYG , should I go for a Full blown, GUI Editor  or something like this.

That’s too much talk in one post; I’ll talk more about “Nested forms and compliance with accessibility standards in the next post.

Mostafa Muhammad studies Medicine at the Al-Azhar University in Cairo, He began working with Mambo in 2005 and has continued developing with PHP and Joomla! ever since. Mostafa has served as a moderator in the Arabic forums and has a strong technical background with interests in 3D graphics, primarily using OpenGL, vector math and C++.

Mentor: Jui-Yu (Ray) Tsai (aka mihu) started programming when he was working on his undergraduate degree. He lives in Los Angeles but is originally from Taiwan. He was impressed with the positive feedback from others and decided to use Joomla!, himself, to build a Web site for his student association. Jui-Yu has been on the Joomla! Quality and Testing Team and is now a member of the Joomla! Development Team. He participates with Joomla! for fun and enjoys contributing to the community.

Dynamic form generation is a functionality that many end users have came to take for granted when using a CMS, The process of form generation could,however, use more simplification.

I'm proposing an extensible, plug-in based Forms component that works natively on 1.5 Framework and allows single-screen form design and nested forms for complex forms while compiling with accessibility standards as far as possible.