This is Part 3 of my series on Writing Components For CiviCRM. Part 1 discussed what a component is, and what it does. Part 2 explained how to use CiviCRM's XML-based data definition language to define your tables. But while your tables may now be in place, CiviCRM doesn't know what to do with your data.
Blogs
Keep up-to-date with blogs from the core team, working groups, developers, users and champions worldwide. Subscribe to our newsletter to receive regular updates by email. We also have an RSS feed.
Here's a snippet of the 1.8 beta release announcement. The complete announcement is here
We are excited to announce that our 1.8 Beta release is now available for download, as well as testing on our demo site. We rely on our dedicated users (that’s you) to install and test the beta in order to make sure we have a quality final release.
We are making pretty good progress towards a 1.8 beta release. A late breaking forum post revealed some bugs with the sql upgrade script. Once we are done with testing that issue, we should be pretty close to announcing a beta candidate for 1.8.
Reporting is a complex issue. To make life easier we decide to support an open source reporting package BIRT from Eclipse. BIRT is definitely quite an impressive package with a great feature set and we are quite glad to have chosen it.
This is Part 2 of my series on Writing Components For CiviCRM. Part 1 discussed what a component is, and what it does. The key tasks were:
Define and manage a set of data base tables.
Set up UI to view and edit contacts that contain its data.
Make the content searchable.
CiviCRM 2.0 Design Series - Simplifying Data Storage and Retrieval for Address, Email and Phone Data
One of our primary objects for the 2.0 release is to find ways to simplify the way data is stored and retrieved in order to make querying data from the DB easier and more scalable/efficient. We're questioning a number of different pieces of the current data model - and one big area is storage of address, email and phone data. Part of this process also involves identifying areas where the data model is "out of touch with reality" (i.e. it imposes unrealistic or artificial constraints on the data).
For the last six months, I've been working on a system called CiviVoter, which is a component of CiviCRM that manages a voter file (the kind you get from your local registrar of voters here in the US) and imports it into CiviCRM.
We've had Deepak and Manish from India and Michal from Poland visiting San Francisco. We've been thinking about the various things we need to accomplish for 2.0 and having a few design / schema meetings. We'll be blogging in detail about various sub-projects over the next few weeks.
In the past few weeks a few events have occured that make us proud of CiviCRM and the community around it. It has also been a good learning experience for some of us. As a growing project, we are glad that to have such a open, supportive community around us.
