[Vtigercrm-developers] Hello and the webform module

[Prasad]

Hi Alan,

Good to see you got started on the developer list.

vtiger CRM uses adodb library: http://adodb.sourceforge.net/
Look at vtigercrm/include/database/PearDatabase.php which uses adodb
functions.

Regards,
Prasad
vtiger Team

On 4/9/08, Alan Lord <alanslists at gmail.com> wrote:
>
> 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
> _______________________________________________
> Reach hundreds of potential candidates - http://jobs.vtiger.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20080409/590a9cb5/attachment-0003.html