Differences from version 8 to 15

@@ -1,46 +1,86 @@

-^Eating my own dog food re SDLC's - [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''
-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
+!!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}
+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",
-!Design, Documentation and Quality Assurance
 !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