Comparing versions
Version 3Current version
Eating my own dog food re SDLC's and Package Maintainer Teams - wolff_borg

Resources

None as yet

Definitions

  • Controller PHP - see Model View Controller - MVC
  • Model PHP - see Model View Controller - MVC
  • 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
    • Model View Controller - MVC 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 Model View Controller - MVC design patterns and keep APIDocumentation a standard for all code developed.

Data Model

None as yet

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}

LibertContent

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(
"me@home.com",
"me@home2.com"
),
"calFBURL" => "http://bitweaver.org/fb/wolff_borg.ifb",
);{CODE}

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",
);{CODE}
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,
);{CODE}

Development

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

TODO

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

 
Eating my own dog food re SDLC's and Package Maintainer Teams - wolff_borg

Resources

None as yet

Definitions


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 (eg unlimited phone numbers in a contacts form) - 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
    • Model View Controller - MVC 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
  • Use of AJAX to provide a more responsive UI - wolff_borg

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 Model View Controller - MVC design patterns and keep APIDocumentation a standard for all code developed.

Data Model

None as yet

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}

LibertContent

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(
"me@home.com",
"me@home2.com"
),
"calFBURL" => "http://bitweaver.org/fb/wolff_borg.ifb",
);{CODE}

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",
);{CODE}
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,
);{CODE}

Development

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

TODO

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
Date/CommentUserIPVersion
02 Sep 2006 (14:03 UTC)
Stephan Borg218.214.1.1136
Current • 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