[Vtigercrm-developers] Hello and the webform module
prasad at vtiger.com
Wed Apr 9 08:31:16 PDT 2008
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
On 4/9/08, Alan Lord <alanslists at gmail.com> wrote:
> Sorry in advance - this is quite a long message...
> 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
> 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
> 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
> 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
> I also have some ideas to develop the webform module further once I get
> the basics working:
> 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.
> The way out is open!
> Reach hundreds of potential candidates - http://jobs.vtiger.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vtigercrm-developers