History of SDLC Template

^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]^
None as yet

* Controller PHP - see ModelViewController
* Model PHP - see ModelViewController
* Attribute - similar to a field in a database table

!Feasibility Study
There were discussion which lead to the idea of a simplified method to create forms based applications, using existing functions and programming methods.

!Analysis and Specifications v1.0 - due 17 July 2005
Requirements for v1.0 are:
* Data fields with the ability of unlimited multiple occurance of attributes - wolff_borg
** Observer/Observable event triggers to aid in synchronisation with external data storage - wolff_borg
* Storage of data in XML format in LibertyContent - lsces, jht001
** Use of LibertyStructures to organise data - xing
** 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

!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 Model
None as yet

Data will be store in LibertyContent ''data'' field in XML format{CODE()}<?xml version="1.0"?><contact>
<cn>Stephan Borg</cn>
<mobile>1234 567 890</mobile>

Once imported into the class, the data would be stored in an array.{CODE()}array(
"cn" => "Stephan Borg",
"givenName" => "Stephan",
"sn" => "Borg",
"mobile" => "1234 567 890",
"uid" => "wolff_borg",
"o" => "Bitweaver",
"mail" => array(
"calFBURL" => "http://bitweaver.org/fb/wolff_borg.ifb",

!!Field Types
Field names would need to be associated with field types, to be displayed and edited by automatically generated forms. A sample field type array would look like this:{CODE()}array(
1 => "text",
2 => "phone",
3 => "email",
4 => "url",
These field types would help choose the appropriate INPUT fields using Smarty functions and possibly perform Javascript validation checks during input.

The content of the record, would likely be passed in an array to the UI generation code.{CODE()}array(
"cn" => 1,
"givenName" => 1,
"sn" => 1,
"mobile" => 2,
"uid" => 1,
"o" => 1,
"mail" => 3,
"calFBURL" => 4,

I suggest we begin developing read-only forms display using the test data above. We could supply the test data through StubsAndMockObects classes which should be kept hard-coded.

Next would be to provide write functions to our Model PHP class and begin building a TestingSuites to ensure data validity on writes. Once confirmed, these functions can be implemented in the Controller PHP file and implemented in the UI. We may want to provide TestingSuites for the Controller PHP files.

!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
26 Jul 2005 (11:03 UTC)
Stephan Borg218.214.1.1132
Current • Source
Stephan Borg218.214.1.1131
View • Compare • Difference • Source