Differences from version 9 to 15

@@ -1,54 +1,34 @@

-^Eating my own dog food re __((System Development Life Cycle - SDLC|SDLC's))__ and __((Package Maintainer Teams))__ - [http://www.bitweaver.org/wolff_borg|wolff_borg]^
+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
+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''
+!Design, Documentation and Quality Assurance
-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
+!!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}
-!Design, Documentation and Quality Assurance
-From initial talks, data will flow in a sequence as shown below:
-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>
 !!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

@@ -65,6 +45,7 @@

 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",

@@ -79,9 +60,27 @@

  "calFBURL" => "http://bitweaver.org/fb/wolff_borg.ifb",
 !Systems Implementation
 !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
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