Download & Extend
CiviNode And Civinode CCK » Issues

Restructure CiviNode to be more modular

Posted by mfredrickson on May 24, 2006 at 3:38pm
Project:CiviNode And Civinode CCK
Version:master
Component:Code
Category:feature request
Priority:normal
Assigned:Torenware
Status:active

Issue Summary

After a brief email exchange with Rob, we've agreed it good to look at restructuring CiviNode to be more modular. For long term use and maintainability, a modular approach has many benefits: greater adoption by the community, simpler fixes, easier code for new developers to read.

Attached is a PDF of my proposed design. The design will require CCK in addition to CiviCRM.

The design has three layers:

  1. CiviCRM + CCK bridge (aka civicrmdata.module): All node data handling can be done through CCK. This simplifies later code by allowing CCK to handle the storage of the data, while civicrmdata.module handles the connection to CiviCRM. Potentially, additional modules could be written with no calls to CiviCRM and minimal node logic. This layer will also have a basic library of interaction functions, but will mostly rely on the CiviCRM API.
  2. CiviNode: This layer uses the fields/widgets in CiviCRMData to create a 'contact' node type. This layer will require CCK to implement import/export functionality. This module will actually be pretty small - not much more than a proof of concept for the system.
  3. Access control and Node factory: These components will be additional modules in the new system, allowing administrators to choose whether to implement the additional CiviNode ACL system, as compared to the built-in CiviCRM system. The node factory utility system will also be an add on.

I realize my diagram does not contain any of the CiviCRM + OG integration. While I haven't investigated this completely, my gut instinct is to move this functionality to OG. Alternatively it could be provided as another add-on module.

This design is not written in stone, but I think it is a good start for debate. Comments, criticisms welcome.

-Mark

AttachmentSize
civinode_proposed_redesign.pdf29.83 KB
Login or register to post comments

Comments

#1

Posted by majortom on January 22, 2007 at 3:58pm

Has any work been done on this redesign? I am very interested in using CiviNode with Drupal 5.x and CiviCRM 1.6 (and soon it seems) 1.7 and I would like to know what is happening with this code.

Thanks.

#2

Posted by mfredrickson on January 25, 2007 at 3:03pm

I can't speak for Rob, but my limited time has been focused elsewhere, and I don't have any plans to return to this project in the foreseeable future. If others are willing to put in the lion's share of the effort, I'd be willing to answer questions, but I don't have a lot of time to muck with CiviCRM internals anymore. :-)

#3

Posted by Torenware on January 25, 2007 at 5:39pm
Assigned to:Anonymous» Torenware

Short answer folks: a 5.x/1.x version is about to go up.

I have done a good piece of the refactoring Mark has suggested. Roughly speaking I've done this:

  • Core CiviNode is support for Drupal UI widgets, Drupal CiviCRM object theming, and the "Drupal compatibility API", + Mark's CiviCRMData module.
  • For now, I've taken most of the "nodifying code" out. I may put some of it back in if someone can give me a compelling use case they've found for it. For myself, I've almost always found that the CCK fields are a better approach, so I'm stickin' with it.
  • If the nodifying stuff isn't needed, you don't really need the access control stuff either, so I've simply factored out that code. Most of the bad bugs in the old version were in this code, so I think this was the way to go.
  • Organic Groups support is currently out of the tree. Big reason is that there just isn't a good way to integrate with OG right now (limitations in OG's node access set up, mostly). I also think that there's a better way to do what people want with CiviCRM Groups on the Drupal side that makes little or no use of OG, and I'm concentrating on that.

I'm hoping that the new 5.0 CiviNode will be up in a few more days. I can actually give interested folks a copy of the current "tar ball", but want to test in a standard 1.6 configuration first: I'm currently working on a highly modified copy of 1.6 (voter file support -- more on that later), and I'm not 100% sure that there are not dependencies in the current CiviNode.

nobody click here