History of LDAPContactsPackage
Version 9
LDAPContactsPackage
Created by: Stephan Borg, Last modification: 11 Jul 2005 (05:47 UTC) by Stephan Borg
Eating my own dog food re System Development Life Cycle - SDLC and Package Maintainer Teams - wolff_borg
Feasibility Study
There have been requests for an LDAP compatible Contacts address book, which was started by lsces. I've provided an overview of LDAPCompatibility here.Analysis and Specifications v1.0 - due 17 July 2005
Requirements for v1.0 are:- Data field compatibility with LDAP ie single contact can have unlimited multiple occurance of attributes - wolff_borg
- Optional auto-update to/from LDAP server (synchronised LibertyContent storage) - wolff_borg
- Optional direct LDAP communications (minimal LibertyContent storage) - wolff_borg
- Storage of contact data in XML format in LibertyContent - lsces, jht001
- Use of LibertyStructures to organise data - xing
- Contacts management should be defined as just another layer of Liberty - jht001, lsces
- If feasible, sub-class LibertyStorage to allow LDAP as a minimal storage mechanism - wolff_borg
- Store variable data like this in a LibertyContent record without needing extra database fields - lsces
- Forms using fieled type plugins to automatically generate, based on XML content - xing
- ModelViewController segregation between the data manipulation and the form display - wolff_borg
- A generic dynamic form that can be applied to other packages - xing, jht001
- A LibertyPlugin for a form element that takes a name, type and value - lsces
- The ability to update the page with values returned from the form dependent on the type values - lsces
- The plugin would take an array (name, type and value) - lsces, xing
- Ideally we need a LibertyContent extension that will return a value(s) for a name element in a page - lsces
- Example: Date field, including calendar type (Julian, Gregorian), Javascript GUI, etc - lsces
- Ability to search generically at an attribute level - lsces
- The search package can scan a LibertyForm page and extract field/value elements and add them to the search indexes - lsces
- Provide plugins for LibertyContent to access Contact records - wolff_borg
Analysis and Specifications v1.1 - TBA
- Storage in other formats (LibertyFormats) - such as LDIF and field_type: value
Resources
This is an interesting interview that talks about LDAP vs XML, and the use of XML for CMS systems- http://www.zope-europe.org/articles/200506/johnmerrells
- http://memberwebs.com/nielsen/code/ldapxml/
- http://whitepapers.zdnet.com/abstract.aspx?promo=50002&docid=110834
- http://www.infoloom.com/gcaconfs/WEB/TOC/t0285_.HTM
Design, Documentation and Quality Assurance
From initial talks, data will flow in a sequence as shown below:XML
Data will be store in LibertyContent data field in XML format{CODE()}<?xml version="1.0"?><contact><cn>Stephan Borg</cn><givenname>Stephan</givenname><sn>Borg</sn><mobile>1234 567 890</mobile><uid>wolff_borg</uid><o>Bitweaver</o><mail>me@home.com</mail><mail>me@home.com</mail><calfburl>http://bitweaver.org/fb/wolff_borg.ifb</calfburl></contact>{CODE}LDIF - LDAP Data Interchange Format
Data coming from an LDAP server would look something like this:{CODE()}dn: cn=Stephan Borg,ou=people,o=bitweavercn: Stephan Borg
givenName: Stephan
sn: Borg
mobile: 1234 567 890
uid: wolff_borg
o: Bitweaver
mail: me@home.com
mail: me@home2.com
calFBURL: http://bitweaver.org/fb/wolff_borg.ifb
objectClass: top
objectClass: inetOrgPerson
objectClass: person
objectClass: organizationalPerson
objectClass: calEntry{CODE}
LibertContent
Once imported into the class, the data would be stored in an array. I have tried to keep the format inline with the array format used by the LDAP PHP commands.{CODE()}array("cn" => "Stephan Borg",
"givenName" => "Stephan",
"sn" => "Borg",
"mobile" => "1234 567 890",
"uid" => "wolff_borg",
"o" => "Bitweaver",
"mail" => array(
"me@home.com",
"me@home2.com"
),
"calFBURL" => "http://bitweaver.org/fb/wolff_borg.ifb",
);{CODE}