Hi Alan,<br><br>Good to see you got started on the developer list. <br><br>vtiger CRM uses adodb library: <a href="http://adodb.sourceforge.net/">http://adodb.sourceforge.net/</a><br>Look at vtigercrm/include/database/PearDatabase.php which uses adodb functions.<br>
<br>Regards,<br>Prasad<br>vtiger Team<br><br><div><span class="gmail_quote">On 4/9/08, <b class="gmail_sendername">Alan Lord</b> <<a href="mailto:alanslists@gmail.com">alanslists@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Sorry in advance - this is quite a long message...<br> ----------<br> <br> Hello.<br> <br> I'm Alan, and I run an Open Source training, consulting and support<br> services business here in the UK.<br> <br> We have been "playing" with vtiger for some time and now would like to<br>
contribute something back.<br> <br> I have recently been looking at the webform module and have some ideas,<br> but I am struggling to get passed first base due to the db abstraction<br> library and some rather obfuscated code...<br>
<br> Anyway, first, A brief idea of what I'd like to do with the webform module:<br> <br> 1. Abstract the client side so that there is minimal or no hardcoding of<br> form parameters and eliminate the need for manual duplication of lists<br>
of php arrays in 5 or 6 places as is now the case.<br> 2. Migrate the forms to be valid XHTML (no tables) with external<br> stylesheet(s).<br> 3. Option to notify admin or other vtiger user by email that a form has<br> been submitted.<br>
4. Introduce a nice and friendly form builder (probably using something<br> like the dojo toolkit to give a good user experience).<br> <br> <br> With respect to the above I have done some work already.<br> <br> 1. During some initial hacking, the client end of the webform package<br>
now has a single array construct which holds the basic form field<br> parameters and labels etc in config.php. This is the only place - on the<br> client side - where changes need to be made to alter your form's basic<br>
field layout and structure. However, the interaction to the server is<br> not fixed. The vtiger file soap/webform.php needs manually hacking in<br> several places to match the client side configuration.<br> 2. This is kind of done.<br>
3. Sort of done. It works but the email notification is done at the<br> client end. This depends on the client server having sendmail(). I'd<br> like to move this function back to vtiger. Don't think it should be too<br>
hard, but haven't looked into it yet.<br> 4. Not started<br> <br> Completing "1." above is giving me a headache!<br> <br> What I am trying to achieve is something along the following lines:<br> <br> *Start the client end "form building process"<br>
*Select the type of form you'd like to make/edit<br> *Upload the schema for the relevant fields from the user's vtiger<br> installation and use that information to create the basic form layout<br> data...<br> <br>
It is here's where I am stuck. Is there any decent documentation on the<br> database abstraction library that is being used? I find even simple<br> queries respond with vast amounts of superfluous data. For example a<br>
query like:<br> <br> "SHOW TABLES LIKE 'vtiger_".$form."%'"<br> <br> responds with the data but also with a tremendous amount of noise. And<br> with that particular query I can't seem to iterate through the result<br>
and filter it because of using a wildcard in the query. Any ideas?<br> <br> My plan is generate an xml schema for the fields that are available for<br> a particular kind of form. This would be used to generate the wsdl on<br>
vtiger and be cached in a local (client-side) file and only updated as<br> and when necessary. The benefit being it will display any custom fields<br> or should vtiger's schema change with a new release, no manual updating<br>
would be necessary.<br> <br> The client side Form Builder would be able to use this data to build the<br> initial UI and when the user has selected the fields to display etc,<br> the "design" will be saved in an XHTML file for deployment along with a<br>
basic stylesheet.<br> <br> **Any help with extracting the data from the db would be most helpful.**<br> <br> I have looked at some of the functions in the MS word module (which gets<br> the "lead" field structure for example, but no schema information) as a<br>
starting point but it doesn't go far enough and also has hardcoded wsdl<br> structures.<br> <br> I also have some ideas to develop the webform module further once I get<br> the basics working:<br> <br> Possibly use a Javascript SOAP library, so no client-side "server<br>
scripting" language like PHP would be needed at all (fully platform<br> agnostic). Or, enable the form to be so standalone that other<br> contributors could write client form processors in other languages like<br> ASP, Ruby, Java etc...<br>
<br> Improvements in end-user functionality such as addition of optional<br> calendar features for using the form for booking appointments/events,<br> adding a unique UUID to individual mail campaign emails (or just<br> campaigns) so when a new user hit's the form, we know how he got<br>
there... And a few others ideas too.<br> <br> Sorry again for the length.<br> <br> Alan<br> <br><br> --<br> The way out is open!<br> <a href="http://www.theopensourcerer.com">http://www.theopensourcerer.com</a><br> _______________________________________________<br>
Reach hundreds of potential candidates - <a href="http://jobs.vtiger.com">http://jobs.vtiger.com</a><br> </blockquote></div><br>