Hello everybody, Thanks beberlei, this rewritten version of the component proposal is more straight to the point imho.
Basically, this component is about defining data structures with constraints, not coupling with any ORM/DBAL/UI component of any sort, and where the objects structure is avalaible along with the object (self-descriptive). Looking forward to read feedback! Regards, James. -- A: Yes, but then I don't understand the question. Q: Can I post your message at the bottom of mine?
--- framework_proposal.txt 2009-02-05 12:09:52.000000000 +0100 +++ validator_proposal.txt 2009-02-05 12:08:46.000000000 +0100 @@ -1,5 +1,5 @@ -eZ Component: FrameworkTools, Requirements -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +eZ Component: Validator, Requirements +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ :Author: James Pic :Revision: $Revision$ :Date: $Date$ @@ -8,14 +8,12 @@ ================ The scope of this document is to describe the requirements for a component -providing classes to implement a SoftwareFramework_ architecture to develop -data-driven applications. -This document does not describe the design of the named component, but only -summarizes the requirements for it to be discussed on the developer mailing -list. Where suitable, design related topics will be touched, but a -dedicated -design document is available, defining APIs, classes and the architectural -structure of the component. +providing classes to implement a structured data validator to develop +data-driven applications. This document does not describe the design of the +named component, but only summarizes the requirements for it to be discussed +on the developer mailing list. Where suitable, design related topics will be +touched, but a dedicated design document is available, defining APIs, classes +and the architectural structure of the component. Note that if you don't understand a term, you should have a look at the section `Clarification of terms`_. @@ -23,97 +21,95 @@ Introduction ============ -The goal of FrameworkTols component is to give users a basis for such -architectures for web applications written in PHP 5. +The goal of the Validator component is to give users a basis for implementing +structured data for applications written in PHP 5. -The compononent shall not provide a fully featured implementation of a -SoftwareFramework_, but should help users to easily create their own, -custom implementations; although Tiein will be implemented to make features -easely usable. - -Developing a SoftwareFramework_ highly involves creating code that is -re-usable independently of the application specific data structures. - -This means, in MVC terms, that changing the data structure should not -cause any change of the Controller, Model or View layer - unless any -has behaviours overloaded for application specific needs. +The component shall not provide a fully featured implementation of a +Repository_, but should help users to easily create their own, custom +implementations; although Tiein will be implemented to make features easily +usable. + +Developing a model driven `Software Framework`_ highly involves creating code +that is re-usable independently of the application specific data structures. + +This means, in MVC terms, that changing the data structure should not cause +any change of the Controller, Model or View layer - unless any has behaviours +overloaded for application specific needs. Data driven applications ------------------------ -Design patterns like `Naked Objects`_ allow to build a data driven -application with high overhead but low cost. +Design patterns like `Naked Objects`_ allow to build a data driven application +with high overhead but low cost. -There is currently no PHP implementations of `Naked Objects`_ design -pattern. +There is currently no PHP implementations of `Naked Objects`_ design pattern. -The PHP object model does not allow to implement this design pattern like -Java +The PHP object model does not allow to implement this design pattern like Java but still allows it to implement it properly, without coupling the data -structure definitions with application specific code of UI, ORM/DBAL ... -(or even: Models, Views or Controller layers). +structure definitions with application specific code of UI, ORM/DBAL ... (or +even: Models, Views or Controller layers). Flexible data structures ------------------------ -eZ Publish currently solves this problematic, but there is no loosly coupled +eZ Publish currently solves this problematic, but there is no loosely coupled component that allows it. The strength of DatabaseSchema_ and PersistentObject_ components is demonstrated when implementing a data structure for a agilely designed application. -The experience shows that in most cases: +The experience shows that in some cases: - a quote must be done before being supplied with detailed data structures. -- it is very hard for the client to allocate budget for the software -engineer +- it is very hard for the client to allocate budget for the software engineer to come on site and detail the data structure. - it is very hard to have a detailed data structure even when the quote was accepted anyway... +Medium-sized project data-driven developers are often asked to add or remove a +field from the data-structure. It currently requires to reflect changes on the +database schema, persistent object and user input definition, as well as html +templates. + Data structures with eZ Components ---------------------------------- -eZ Components does not yet provide a library to design the data structure -once -and only once. Developping generic frameworks providing a generic CRUD_ -controller require loading both the DatabaseSchema_ and PersistentObject_ -components: +eZ Components does not yet provide a library to design the data structure once +and only once. Developing generic frameworks providing a generic CRUD_ +controller require loading the DatabaseSchema_, PersistentObject_ and +UserInput_ components: - DatabaseSchema_ provides complete information about fields, -- PersistentObject_ provides complete information about objects and - relations. +- PersistentObject_ provides complete information about objects and relations. +- UserInput_ provides complete information about some types of constraints. -Three solutions are possible: +Solutions exist: -- Embed the field information in PersistentObject_, deriving from its - original requirements, making it able to replace DatabaseSchema_ with high - overhead. -- Embed the relations information in DatabaseSchema_, but then - PersistentObject_ would still be needed or else arrays and arrays of -arrays +- Embed the field and constraints information in PersistentObject_, deriving + from its original requirements, making it able to replace DatabaseSchema_ + with high overhead. +- Embed the relations and constraints information in DatabaseSchema_, but then + PersistentObject_ would still be needed or else arrays and arrays of arrays would have to be dealt with. -- Use a third component to define the complete data structure: fields and - relations at once. Provide tieins to generate definitions not only for - DatabaseSchema_ and PersistentObject_, but also other components like - UserInput_ or Workflow_. - -Even if any of the two first solutions where selected, keep in mind that -UserInput_ definitions should also be parsed for constraints. +- Embed the field and relations informations in UserInput_, heavily deriving + its requirements with high overhead. +- Use a third component to define the complete data structure: fields, + relations and constraints at once. Provide tieins to generate definitions + not only for DatabaseSchema_ and PersistentObject_, but also other + components like UserInput_ or Workflow_. Component integration ===================== eZ Components already provide some components that are useful when -implementing a SoftwareFramework_. However, one basic goal of eZ Components -is to keep each component as independent as possible and to realize -dependencies through so-called tie-in components. Therefore the mechanisms -realized in an SoftwareFramework component should be that far abstracted, -that other components can be tied in and provide only very basic -implementations on its own. This also allows users to implement their own -mechanisms. The following components have been identified as possible -tie-ins: +implementing a `Software Framework`_. However, one basic goal of eZ Components is +to keep each component as independent as possible and to realize dependencies +through so-called tie-in components. Therefore the mechanisms realized in an +`Software Framework`_ component should be that far abstracted, that other +components can be tied in and provide only very basic implementations on its +own. This also allows users to implement their own mechanisms. The following +components have been identified as possible tie-ins: - PersistentObject_ (models) - DatabaseSchema_ (models) @@ -121,8 +117,7 @@ - MvcTools_ (user interface) - UserInput_ (controllers) -.. _PersistentObject: -http://ezcomponents.org/docs/tutorials/PersistentObject +.. _PersistentObject: http://ezcomponents.org/docs/tutorials/PersistentObject .. _DatabaseSchema: http://ezcomponents.org/docs/tutorials/DatabaseSchema .. _MvcTools: http://ezcomponents.org/docs/tutorials/MvcTools .. _UserInput: http://ezcomponents.org/docs/tutorials/UserInput @@ -130,81 +125,67 @@ For each of these components a tie-in component could considered to be implemented at a later stage. This should be kept in mind when designing the -classes/interfaces for the FrameworkTools component. +classes/interfaces for the Validator component component. Design requirements =================== This section summarizes the requirements. -No dependencies - Allowing users to define a data structure OAOO_, without coupling with - anything such as an ORM_, a DBAL_, an MVC_ implementation, a UI_ component - ... - This requirement is default to eZ Components coding standards. - -Topnotch API - This means making it straight-forward to parse a data structure definition -to - generate either: javascript validation, php validation, model layer - (queries) ... based on the user-framework assumptions. - -Customizable - Users should be able to add protocol or business specific attributes -without - having to extend a provided class? - -Two way development - This means being able to use the tool to generate definitions and use the -tool - to reverse engineer existing db/objects to generate the definitions. - -No data structure change propagation - This means being able to use the data structure definitions without - specificity: adding or removing fields should not require any change in - any MVC layers. - This is optional because there are cases when it's impossible, not only - because of bad Model, View or Controller design. - -Support for constraints - This means being able to add constraints, even if a RDBMS doesn't support - it: it would still be *very* useful, as it's a rare feature in nowadays - data structure framework definitions api. - This can be used for PHP and Javascript level validation if unavailable in - a RDBMS: keep in mind this component should not limit the user on the - selected model layer implementation. - -Definitions consistency - Validation of definitions of data structures should be possible, but - optional. - -State and data structure definitions together - Developing re-usable, data-structure independent libraries requires to -work - with the data structure definition, as well as the object bound to a -state. - -Tracking definitions - An application's collection of data structure definitions should be - accessible by the generic library part of the user implemented framework. - -Tracking objects states - User's selected ORM may or may not implement an identity map. The -component - should implement an identity map for objects that are bound to a state but - which business logic is not part of the ORM. This is not only to allow - document-based databases, but also to allow making objects which states do - not need to be saved in a database. - -One level higher than php variable types - The user should be able to define data structure field types that are not -as - simple as a php variable type (example: email field, url field ...). - -Serializable and exportable states of data structure definitions - Data structure definitions should be serializable and with an - exportable state: to save data structures in a database instead of some - PHP configuration file. This can be useful for eZ Publish. +No dependencies Allowing users to define a data structure OAOO_, without +coupling with anything such as an ORM_, a DBAL_, an MVC_ implementation, a UI_ +component ... This requirement is default to eZ Components coding standards. + +Topnotch API This means making it straight-forward to parse a data structure +definition to generate either: javascript validation, php validation, model +layer (queries) ... based on the user-framework assumptions. This requirement +is default to eZ Components coding standards. + +Customizable Users should be able to add protocol or business specific +attributes without having to extend a provided class? Allowing users to add +custom options to provided validator classes. + +Two way development This means being able to use the tool to generate +definitions and use the tool to reverse engineer existing db/objects to +generate the definitions. + +No data structure change propagation This means being able to use the data +structure definitions without specificity: adding or removing fields should +not require any change in any MVC layers. This is optional because there are +cases when it's impossible, not only because of bad Model, View or Controller +design. + +Support for constraints This means being able to add constraints, even if a +RDBMS doesn't support it: it would still be useful, as it's a rare feature in +nowadays data structure framework definitions api. This can be used for PHP +and Javascript level validation if unavailable in a RDBMS: this component +should not limit the user on the selected model layer implementation anyway. + +Definitions consistency Validation of definitions of data structures should be +possible, but optional. + +State and data structure definitions together Developing re-usable, +data-structure independent libraries requires to work with the data structure +definition, as well as the object bound to a state. + +Tracking definitions An application's collection of data structure definitions +should be accessible by the generic library part of the user implemented +framework. + +Tracking objects states User's selected ORM may or may not implement an +identity map. The component should implement an identity map for objects that +are bound to a state but which business logic is not part of the ORM. This is +not only to allow document-based databases, but also to allow making objects +which states do not need to be saved in a database. + +One level higher than php variable types The user should be able to define +data structure field types that are not as simple as a php variable type +(example: email field, url field ...). + +Serializable and exportable states of data structure definitions Data +structure definitions should be serializable and with an exportable state: to +save data structures in a database instead of some PHP configuration file. +This can be useful for eZ Publish. Special Considerations ====================== @@ -229,8 +210,7 @@ In addition, this component should neither provide any automation facilities (e.g. code generation, deployment) nor integration with components that are -not explicitly needed by it (e.g. Configuration, Authentication or -Database). +not explicitly needed by it (e.g. Configuration, Authentication or Database). Integration with such components could: - Be build using a tie-in @@ -240,6 +220,8 @@ Clarification of terms ====================== +.. _Repository: http://martinfowler.com/eaaCatalog/repository.html +.. _Software Framemork: http://en.wikipedia.org/wiki/Software_Framework .. _MVC: http://en.wikipedia.org/wiki/Model-view-controller .. _UI: http://en.wikipedia.org/wiki/UI .. _ORM: http://en.wikipedia.org/wiki/Object-relational_mapping @@ -247,7 +229,6 @@ .. _Naked Objects: http://en.wikipedia.org/wiki/Naked_objects .. _CRUD: http://en.wikipedia.org/wiki/Create,_read,_update_and_delete .. _OAOO: http://en.wikipedia.org/wiki/Once_and_only_once -.. _SoftwareFramemork: http://en.wikipedia.org/wiki/Software_Framework .. Local Variables: @@ -255,4 +236,3 @@ fill-column: 78 End: vim: et syn=rst tw=78 -
eZ Component: Validator, Requirements ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ :Author: James Pic :Revision: $Revision$ :Date: $Date$ Target and scope ================ The scope of this document is to describe the requirements for a component providing classes to implement a structured data validator to develop data-driven applications. This document does not describe the design of the named component, but only summarizes the requirements for it to be discussed on the developer mailing list. Where suitable, design related topics will be touched, but a dedicated design document is available, defining APIs, classes and the architectural structure of the component. Note that if you don't understand a term, you should have a look at the section `Clarification of terms`_. Introduction ============ The goal of the Validator component is to give users a basis for implementing structured data for applications written in PHP 5. The component shall not provide a fully featured implementation of a Repository_, but should help users to easily create their own, custom implementations; although Tiein will be implemented to make features easily usable. Developing a model driven `Software Framework`_ highly involves creating code that is re-usable independently of the application specific data structures. This means, in MVC terms, that changing the data structure should not cause any change of the Controller, Model or View layer - unless any has behaviours overloaded for application specific needs. Data driven applications ------------------------ Design patterns like `Naked Objects`_ allow to build a data driven application with high overhead but low cost. There is currently no PHP implementations of `Naked Objects`_ design pattern. The PHP object model does not allow to implement this design pattern like Java but still allows it to implement it properly, without coupling the data structure definitions with application specific code of UI, ORM/DBAL ... (or even: Models, Views or Controller layers). Flexible data structures ------------------------ eZ Publish currently solves this problematic, but there is no loosely coupled component that allows it. The strength of DatabaseSchema_ and PersistentObject_ components is demonstrated when implementing a data structure for a agilely designed application. The experience shows that in some cases: - a quote must be done before being supplied with detailed data structures. - it is very hard for the client to allocate budget for the software engineer to come on site and detail the data structure. - it is very hard to have a detailed data structure even when the quote was accepted anyway... Medium-sized project data-driven developers are often asked to add or remove a field from the data-structure. It currently requires to reflect changes on the database schema, persistent object and user input definition, as well as html templates. Data structures with eZ Components ---------------------------------- eZ Components does not yet provide a library to design the data structure once and only once. Developing generic frameworks providing a generic CRUD_ controller require loading the DatabaseSchema_, PersistentObject_ and UserInput_ components: - DatabaseSchema_ provides complete information about fields, - PersistentObject_ provides complete information about objects and relations. - UserInput_ provides complete information about some types of constraints. Solutions exist: - Embed the field and constraints information in PersistentObject_, deriving from its original requirements, making it able to replace DatabaseSchema_ with high overhead. - Embed the relations and constraints information in DatabaseSchema_, but then PersistentObject_ would still be needed or else arrays and arrays of arrays would have to be dealt with. - Embed the field and relations informations in UserInput_, heavily deriving its requirements with high overhead. - Use a third component to define the complete data structure: fields, relations and constraints at once. Provide tieins to generate definitions not only for DatabaseSchema_ and PersistentObject_, but also other components like UserInput_ or Workflow_. Component integration ===================== eZ Components already provide some components that are useful when implementing a `Software Framework`_. However, one basic goal of eZ Components is to keep each component as independent as possible and to realize dependencies through so-called tie-in components. Therefore the mechanisms realized in an `Software Framework`_ component should be that far abstracted, that other components can be tied in and provide only very basic implementations on its own. This also allows users to implement their own mechanisms. The following components have been identified as possible tie-ins: - PersistentObject_ (models) - DatabaseSchema_ (models) - Workflow_ (crud controller) - MvcTools_ (user interface) - UserInput_ (controllers) .. _PersistentObject: http://ezcomponents.org/docs/tutorials/PersistentObject .. _DatabaseSchema: http://ezcomponents.org/docs/tutorials/DatabaseSchema .. _MvcTools: http://ezcomponents.org/docs/tutorials/MvcTools .. _UserInput: http://ezcomponents.org/docs/tutorials/UserInput .. _Workflow: http://ezcomponents.org/docs/tutorials/Workflow For each of these components a tie-in component could considered to be implemented at a later stage. This should be kept in mind when designing the classes/interfaces for the Validator component component. Design requirements =================== This section summarizes the requirements. No dependencies Allowing users to define a data structure OAOO_, without coupling with anything such as an ORM_, a DBAL_, an MVC_ implementation, a UI_ component ... This requirement is default to eZ Components coding standards. Topnotch API This means making it straight-forward to parse a data structure definition to generate either: javascript validation, php validation, model layer (queries) ... based on the user-framework assumptions. This requirement is default to eZ Components coding standards. Customizable Users should be able to add protocol or business specific attributes without having to extend a provided class? Allowing users to add custom options to provided validator classes. Two way development This means being able to use the tool to generate definitions and use the tool to reverse engineer existing db/objects to generate the definitions. No data structure change propagation This means being able to use the data structure definitions without specificity: adding or removing fields should not require any change in any MVC layers. This is optional because there are cases when it's impossible, not only because of bad Model, View or Controller design. Support for constraints This means being able to add constraints, even if a RDBMS doesn't support it: it would still be useful, as it's a rare feature in nowadays data structure framework definitions api. This can be used for PHP and Javascript level validation if unavailable in a RDBMS: this component should not limit the user on the selected model layer implementation anyway. Definitions consistency Validation of definitions of data structures should be possible, but optional. State and data structure definitions together Developing re-usable, data-structure independent libraries requires to work with the data structure definition, as well as the object bound to a state. Tracking definitions An application's collection of data structure definitions should be accessible by the generic library part of the user implemented framework. Tracking objects states User's selected ORM may or may not implement an identity map. The component should implement an identity map for objects that are bound to a state but which business logic is not part of the ORM. This is not only to allow document-based databases, but also to allow making objects which states do not need to be saved in a database. One level higher than php variable types The user should be able to define data structure field types that are not as simple as a php variable type (example: email field, url field ...). Serializable and exportable states of data structure definitions Data structure definitions should be serializable and with an exportable state: to save data structures in a database instead of some PHP configuration file. This can be useful for eZ Publish. Special Considerations ====================== User defined data structures should not require to load any interface or abstract class to implement a custom business logic, the user is free to use eZ Publish-like model layer or "regular" model layers (one table per object, requiring database schema updates). We should keep testing capabilities for the extensions to this component and the applications build upon it in mind during the design and implementation phase. We cannot provide the testing environment itself: - Does not fit into the component - Our test "component" is not an official component and can only be used to test eZ Components themselves. However, we could provide detailed information and possibly some helper classes for the testing of applications build on this component. In addition, this component should neither provide any automation facilities (e.g. code generation, deployment) nor integration with components that are not explicitly needed by it (e.g. Configuration, Authentication or Database). Integration with such components could: - Be build using a tie-in - Be part of a potential "Framework" component/package stuff that might be created in future. Clarification of terms ====================== .. _Repository: http://martinfowler.com/eaaCatalog/repository.html .. _Software Framemork: http://en.wikipedia.org/wiki/Software_Framework .. _MVC: http://en.wikipedia.org/wiki/Model-view-controller .. _UI: http://en.wikipedia.org/wiki/UI .. _ORM: http://en.wikipedia.org/wiki/Object-relational_mapping .. _DBAL: http://en.wikipedia.org/wiki/DBAL .. _Naked Objects: http://en.wikipedia.org/wiki/Naked_objects .. _CRUD: http://en.wikipedia.org/wiki/Create,_read,_update_and_delete .. _OAOO: http://en.wikipedia.org/wiki/Once_and_only_once .. Local Variables: mode: rst fill-column: 78 End: vim: et syn=rst tw=78
-- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
