20 July, 2009
Filed under Architecture
Some recent discussions and debates about Active Record and Data Mapper have popped up in the context of new architectural proposals for CiviCRM from Dharmatech and raSANTIAGO. We think it is important that the differences between each is known and to clarify what are some erroneous perceptions. This is not to claim that either design pattern is above criticism. It is to say, that there are some misperceptions that prevent a more intelligent discussion of the trade-offs between these two design patterns. Our hope is to bring some clarity to this discussion. What is Active Record

     Active Record, properly defined, is a design pattern where an object is represented as a record on a table in a relational database. As most know at this point this has been the ORM design pattern of choice in Ruby on Rails(RoR), although that is starting to change a bit. Because of the assumption of "one object - one record" there are a lot of...

Read more
15 July, 2009
Filed under Architecture

Current CiviCRM architecture pitfalls

rasantiago has proposed a new CiviCRM architecture with details of the ORM layer. Torenware commented on the latter and mentioned some particular scalability issues.  Our own experience with the Active Record design pattern proposed by rasantiago is that it works well for small projects but doesn't scale well.  We believe that CiviCRM is now... Read more
08 July, 2009
Filed under Architecture
This is a follow up to our last post proposing a new architecture for CiviCRM. Much appreciation for everyone's patience. Following from our last post we want to go over the use of Doctrine, a PHP implementation of the Active Record design pattern made popular through Ruby on Rails. The Doctrine Project has done a great job of maintaining detailed documentation and has a lot of features that we believe everyone will find useful when working with CiviCRM objects. We have posted some of our working code for the new ORM and REST API here at git hub.We have given this code set the working name civiBASE.
For those who are not familiar with Active Records and ORM a little background will help. An object relational mapping (ORM) layer translates objects... Read more
22 June, 2009
Filed under Architecture
Here at raSANTIAGO we are entering our third year with CiviCRM and still find ourselves struggling to make desired changes to the codebase. Too often we have expressed desired to re-architect and re-factor the CiviCRM. Recently we have completed two major projects that had us deeper in the codebase then before and realizing that we had to stop complaining. So we set ourselves to figuring out a good target architecture and a migration path that would not interfere with current development but give us the opportunity to engineer in patterns which have produced stable, extensible and maintainable systems for us. In the process, we wanted to deal with serious issues like advancing the API, advance our abilities to test and radically increase code reuse.
After a lot of work and prototyping we think we may have found an architecture that will work and a path to that architecture. From this work we offer a... Read more
03 February, 2009
Filed under v2.2, Architecture
Do you wish you could configure custom fields to store Employment History, Educational Background, Volunteer Skills or other types of information where you may need to enter multiple sets of values for a contact? Starting with CiviCRM 2.2, you can do just that. For example, if you need to collect Employment History - you might have fields for Job Title, Start Date, End Date, and Reason for Leaving. Enabling the "multiple records" setting in that custom data group will allow you to enter that information for multiple jobs. You can also set the maximum number of records which can be recorded per contact (you might only want data for the three most recent jobs).

How do I set up a multiple-record custom data group?

  • Go to Administer CiviCRM » Customize » Custom Data
  • Click "New Group of Custom Fields"
  • Select Contacts, Individuals, Households or Organizations for "Used For" record type.
  • ...
Read more
22 December, 2008
By shot
Filed under v2.3, Architecture

As the various localisations of CiviCRM get traction, the first localised versions of documentation pages begin to show up – and this brings us to the issue of how to internationalise these of the CiviCRM strings (texts) that contain links to documentation pages so that when a given string is translated to, say, German, it also refers to the German version of the documentation page (if such is present).

For previous and current CiviCRM versions (including the upcoming CiviCRM 2.2), when we internationalised a string, we wanted to leave the link to the documentation page outside of the string, like this: {ts 1=http://wiki.civicrm.org/…}Read more at %1{/ts}.

This approach has two major benefits:

  • The translators are not bothered to retype the link letter-to-letter in their translations (any errors here would mean that the link stops working), and
  • if the link ever changes, the string (‘Read more at %1’) doesn’t, and...
Read more
05 December, 2008
By michal

It's that time of year again!

No, not what you think. :-) It's the time of year when new a CiviCRM version is behind the door, and it has cool new features. Code freeze is going to be introduced any day now - and we'll move on to quality assurance, alphas, betas and other equally exciting stuff.

Let me briefly introduce you to two new 2.2 features: one of them already mentioned here and there - Personal Contribution Pages (PCP), and a "last minute" addition - Soft Credits.

To present one of the aspects of usefulness of PCP, let me tell you about my approach to personal involvement with social campaigns... There are some that I personally would like to get involved with a bit more than just donating money. I would like these campaigns to grow, get the largest outreach possible and I'm even willing to put some personal time into it. However, I usually do not have enough of it to volunteer. CiviCRM's new Personal Contribution Pages (PCP) feature can be helpful in...

Read more
02 November, 2008
By lobo
Filed under v2.2, Architecture, CiviCRM

The CiviCRM core team is currently meeting in San Francisco. We tend to meet 2-3 times a year. These meetings help us crank out a few large projects as a group and also help improve our communication when we return to our respective home bases. The focus of the San Francisco meetup has been on CiviCase, US PIRG projects and a few features from the 2.2 roadmap.

Our group (kurund, yashodha and me) have been working on extending custom groups with two new features. In 2.2 a custom group can be designated to hold multiple values. This allows a contact (or relationship/group/activity) to have a 1 to n relationship with a custom group. One use cases for this is storing educational history of a contact. A custom group with...

Read more
27 October, 2008
By lobo
Filed under Architecture, CiviCRM

Implementing support for multiple organizations with hierarchy is one of the main themes of the phase 2 part of the CiviCRM / The Public Interest Network (PIN) project. PIN has a fairly complex structure. It is a federation of organizations which include US PIRG, Environment America and others. It is made up the National PIN organization and has a number of child organizations at the National Level. One of them is Environment America (EA). The org chart of EA can be found here.

EA National has a few groups at the national level (EA National Members, All Online Activists, Other Aggregate Groups). It also has a lot of sub organizations ( EA California, EA Colorado and approx 30 other state organizations). Each State Chapter has a few groups at the state level (EA California Members...

Read more
19 October, 2008
By kurund
Filed under v2.2, Architecture

Lately there has been lot of confusion using Name, Title/Label and Value. There is also a lot of inconsistency in code and database, hence we are planning to fix it in CiviCRM v2.x release.

Lets take an example of Participant Status, 'Registered'. In this case Name will be 'Registered', value will be an integer from 1..N (this depends on each install) and Label/title can be "Registered" or "I will come" etc. (or a localized version of the word/phrase).

Basic rules are:

  • Name: This is fixed value and cannot be changed by user. This is used internally in the code base to do certain actions. This will typically be in english.
  • Title/Label: This is user editable field and can be translated. This will be displayed in the system.
  • Value: Actual value that is stored in database.

There are few tables where we have adopted correct approach, like "civicrm_option_value". In this table we have separate fields name...

Read more