| -^Eating my own dog food re SDLC's - [http://www.bitweaver.org/wolff_borg|wolff_borg]^
|
| {maketoc}
|
| +!!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] |
| + |
| +!!Definitions |
| +None as yet |
| + |
| !Feasibility Study
|
| -There have been requests for an LDAP compatible Contacts address book, which was started by [http://www.bitweaver.org/lsces|lsces]. I've provided an overview of LDAPCompatibility here.
|
| -!Analysis and Specifications v1.0 - due 17 July 2005
|
| +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
|
| -* 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 |
| +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} |
|
|
| -!Design, Documentation and Quality Assurance
|
| -TODO
|
| !Development
|
| TODO
|
| + |
| !Systems Implementation
|
| TODO
|
| + |
| !Systems Maintenance
|
| -TODO |
| +!!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 |
| + |