[Vtigercrm-developers] Hello and the webform module

[Alan Lord]

Sorry in advance - this is quite a long message...
----------

Hello.

I'm Alan, and I run an Open Source training, consulting and support 
services business here in the UK.

We have been "playing" with vtiger for some time and now would like to 
contribute something back.

I have recently been looking at the webform module and have some ideas, 
but I am struggling to get passed first base due to the db abstraction 
library and some rather obfuscated code...

Anyway, first, A brief idea of what I'd like to do with the webform module:

1. Abstract the client side so that there is minimal or no hardcoding of 
form parameters and eliminate the need for manual duplication of lists 
of php arrays in 5 or 6 places as is now the case.
2. Migrate the forms to be valid XHTML (no tables) with external 
stylesheet(s).
3. Option to notify admin or other vtiger user by email that a form has 
been submitted.
4. Introduce a nice and friendly form builder (probably using something 
like the dojo toolkit to give a good user experience).


With respect to the above I have done some work already.

1. During some initial hacking, the client end of the webform package 
now has a single array construct which holds the basic form field 
parameters and labels etc in config.php. This is the only place - on the 
client side - where changes need to be made to alter your form's basic 
field layout and structure. However, the interaction to the server is 
not fixed. The vtiger file soap/webform.php needs manually hacking in 
several places to match the client side configuration.
2. This is kind of done.
3. Sort of done. It works but the email notification is done at the 
client end. This depends on the client server having sendmail(). I'd 
like to move this function back to vtiger. Don't think it should be too 
hard, but haven't looked into it yet.
4. Not started

Completing "1." above is giving me a headache!

What I am trying to achieve is something along the following lines:

*Start the client end "form building process"
*Select the type of form you'd like to make/edit
*Upload the schema for the relevant fields from the user's vtiger 
installation and use that information to create the basic form layout 
data...

It is here's where I am stuck. Is there any decent documentation on the 
database abstraction library that is being used? I find even simple 
queries respond with vast amounts of superfluous data. For example a 
query like:

  "SHOW TABLES LIKE 'vtiger_".$form."%'"

responds with the data but also with a tremendous amount of noise. And 
with that particular query I can't seem to iterate through the result 
and filter it because of using a wildcard in the query. Any ideas?

My plan is generate an xml schema for the fields that are available for 
a particular kind of form. This would be used to generate the wsdl on 
vtiger and be cached in a local (client-side) file and only updated as 
and when necessary. The benefit being it will display any custom fields 
or should vtiger's schema change with a new release, no manual updating 
would be necessary.

The client side Form Builder would be able to use this data to build the 
initial UI and when the user has selected the fields to display etc, 
the "design" will be saved in an XHTML file for deployment along with a 
basic stylesheet.

**Any help with extracting the data from the db would be most helpful.**

I have looked at some of the functions in the MS word module (which gets 
the "lead" field structure for example, but no schema information) as a 
starting point but it doesn't go far enough and also has hardcoded wsdl 
structures.

I also have some ideas to develop the webform module further once I get 
the basics working:

Possibly use a Javascript SOAP library, so no client-side "server 
scripting" language like PHP would be needed at all (fully platform 
agnostic). Or, enable the form to be so standalone that other 
contributors could write client form processors in other languages like 
ASP, Ruby, Java etc...

Improvements in end-user functionality such as addition of optional 
calendar features for using the form for booking appointments/events, 
adding a unique UUID to individual mail campaign emails (or just 
campaigns) so when a new user hit's the form, we know how he got 
there... And a few others ideas too.

Sorry again for the length.

Alan

-- 
The way out is open!
http://www.theopensourcerer.com