Version 13


Created by: Lee LaMont Bell Jr., Last modification: 11 Jul 2005 (08:29 UTC) by Lee LaMont Bell Jr.
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


This is an interesting interview that talks about LDAP vs XML, and the use of XML for CMS systems
These talk about using XML with LDAP

Design, Documentation and Quality Assurance

From initial talks, data will flow in a sequence as shown below. I'm hoping we can use this data as test data to begin programming StubsAndMockObects to aid in developing TestingSuites, which will dramatically speed up the development process. Other notes about development - lets try to stay within the boundaries of CodingGuidelines, ClassStructre, ObjectOrientation and ModelViewController design patterns and keep APIDocumentation a standard for all code developed.


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></mail><mail></mail><calfburl></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=bitweaver
cn: Stephan Borg
givenName: Stephan
sn: Borg
mobile: 1234 567 890
uid: wolff_borg
o: Bitweaver
objectClass: top
objectClass: inetOrgPerson
objectClass: person
objectClass: organizationalPerson
objectClass: calEntry{CODE}


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(
"calFBURL" => "",



Systems Implementation


Systems Maintenance

Package Maintainer Team

See Package Maintainer Teams for details and requirements of each of the roles.
  • Steering Committee
    • wolff_borg
    • lsces
    • xing
    • jht001
  • Key Users (Creation of user acceptance procedures)
    • wolff_borg
    • lsces
    • jht001
  • Training (User documentation and tutorials)
    • volunteers?
  • Quality Assurance (Ensure package functionality from the lowest API levels using TestingSuites)
    • wolff_borg
  • Developers (Try and keep the data and presentation code segregated(:eek:))
    • wolff_borg
    • lsces
    • xing
    • jht001
    • StarRider (Forms & Plugins)
  • Support (Upgrade/migration paths and support)
    • wolff_borg

Page History
15 Jul 2005 (15:02 UTC)
Removed replicated functionality from LibertyForms
Stephan Borg218.214.1.11315
Current • Source
Stephan Borg218.214.1.11314
View • Compare • Difference • Source
Lee LaMont Bell Jr.
View • Compare • Difference • Source
Stephan Borg218.214.1.11312
View • Compare • Difference • Source
Stephan Borg218.214.1.11311
View • Compare • Difference • Source
Stephan Borg218.214.1.11310
View • Compare • Difference • Source
Stephan Borg218.214.1.1139
View • Compare • Difference • Source
James Thompson64.65.89.2278
View • Compare • Difference • Source
Stephan Borg218.214.1.1137
View • Compare • Difference • Source
Stephan Borg218.214.1.1136
View • Compare • Difference • Source
Stephan Borg218.214.1.1135
View • Compare • Difference • Source
Stephan Borg218.214.1.1134
View • Compare • Difference • Source
Stephan Borg218.214.1.1133
View • Compare • Difference • Source
Stephan Borg218.214.1.1132
View • Compare • Difference • Source
Stephan Borg218.214.1.1131
View • Compare • Difference • Source