CiviCRM Developer Hack-a-thon: Days 1-3

A few members of the CiviCRM core team (dave, yashodha, michal and kurund) are visiting us in Nelson, NZ. We get together a couple of times a year which is quite helpful when we all return to various parts of the globe. This also gives the team a chance to visit and explore new places. For this meeting, we decided to focus on improving a couple of things for the CiviCRM v2.1 release. The projects we decided to focus on are: AJAX widgets, Unit Testing, Component Architecture and Events. We focussed on Dojo and AJAX for the first week. The widget that my group tackled were:

• WYSIWYG editors. Most folks were not too happy with the Dojo editor. In v2.1 we decided to give folks a choice between a couple of editors. In the 2.1 release we will give folks an option between TinyMCE and FCKEditor. There was a QuickForm extension for FCKEditor. This seemed a nice model, so we wrote a similar class to handle TinyMCE and the Dojo Editor. We also added a config option so folks can switch editors. This should make it a bit easy for folks who are interested in adding their favorite WYSIWYG editor. For 2.1, we'll enable the editor in a few textareas across the system. The relevant issue is here. If there are other screens where a WYSIWYG editor is useful, please do comment on the blog or issue
• Building an AJAX enabled hierarchical select widget. An example of a hierarchical selector is the Country and State selectors. The values in the State selector is dependent on the value chosen in the Country Select element. We use hierarchical selector in a few different places, mapping steps of import and export. of contacts, search builder and custom field data and html type. Thanx to the hard work by Deepak we have a good working hierarchical selector in remote mode (i.e. fetching the data remotely from the server). Deepak is currently adding local mode support so we avoid the multiple trips to the server. This is a essential, otherwise we would make n number of calls for each select row (where n is the number of select elements). A typical import/export has 10+ fields, so this multiplies quickly

I also ran into yet another forum post that requested proximity searching. i.e. give me all the contacts that live within a radius of XX km / miles from this address. This is easily addressed by building a custom search component. the drupal location module had the trignometry equations to calculate this, so i quickly hooked up a custom search that takes in a address and distance, and returns the contacts that live within a distance of the given address. You can get the code from our svn here. Custom Search is definitely working out quite nicely :)