Comparing versions
Version 9Current version
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
These talk about using XML with LDAP
  • 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=bitweaver
cn: 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}

Development

TODO

Systems Implementation

TODO

Systems Maintenance

TODO
 

Resources

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

Definitions

None as yet

Feasibility Study

I have the requirement for an LDAP compatible Contacts address book. I've provided an overview of LDAPCompatibility here.

Analysis and Specifications v1.0

The initial design will be based upon LibertyForms - SDLC and will act as an add-on to provide the following.

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
    • If feasible, sub-class LibertyStorage to allow LDAP as a minimal storage mechanism - wolff_borg
  • Provide plugins for LibertyContent to access Contact records - wolff_borg

Design, Documentation and Quality Assurance

TODO

Data Model

Not a very good diagram, but a start in understanding how this all fits together:{CODE()} UI Form -> LibertyContent (data/type array) -> LDAP server (LDIF - optional component){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
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}

Development

TODO

Systems Implementation

TODO

Systems Maintenance

Package Maintainer Team

See Package Maintainer Teams for details and requirements of each of the roles.
  • Steering Committee
    • wolff_borg
  • Key Users (Creation of user acceptance procedures)
    • wolff_borg
  • 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
    • StarRider (Forms & Plugins)
  • Support (Upgrade/migration paths and support)
    • wolff_borg

Page History
Date/CommentUserIPVersion
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.68.95.137.17213
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