Re: [Components] Validator/Repository component proposal requirements rewrite
Hello everybody, Added requirement: - Provide data structure definition merge algorythms implementations. Added question: - Shouldn't the validator classes be part of Base? Any feedback will be appreciated! 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 domain-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 Description --- The goal of the Validator component is to give users a basis for implementing structured data for applications written in PHP 5. eveloping a model driven `Software Framework`_ requires coding a re-usable API, loosely coupled with the application specific data structures itself. 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 - making it much easier to test any M, V, C layers. Current implementation -- A hack for javascript hack for Django admin app was releasing under WTFPL license: http://www.djangosnippets.org/snippets/1358/ It is useful with model-inheritance or metaclasses. This component should not require metaclasses or validator-wrapper inheritance, but would make it possible. Component integration = eZ Components already provides libraries that are useful for implementing a `Software Framework`_. 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. A repository implementation could be provided, coupling phpillow_, a CouchDB DBAL. Design requirements === - A data structure definition coded with the Validator component should not require loading any library other than the Validator compnonent and user defined classes (no UI_, ORM_, DBAL_, MVC_ implementations ...). - Structured data should contain their own definitions. - Support for two-way development: reverse engineer existing storage data structures. - Never require data structure change propagation: let the user concentrate on his application specific `Software Framework`_. - Support for client (PHP) side state full constraints (validator mutation). - Data structure validation, diff. - Support for data structure validators encapsulation: validator wrapping. - Support for validators agregating and inheritance. - Support for data structures creation on-the-fly. - Support for multiple persistency design: - RDBMS_ - eZPublish_ - CouchDB_ - Provide a fixture generator. - Provide data structure definition merge algorythms implementations. Special Considerations == Shouldn't the validation classes be part of Base? 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. 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
Re: [Components] Validator/Repository component proposal requirements rewrite
Hello everybody, Added requirement: - Provide a fixture generator. Any feedback will be appreciated! 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 domain-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 Description --- The goal of the Validator component is to give users a basis for implementing structured data for applications written in PHP 5. eveloping a model driven `Software Framework`_ requires coding a re-usable API, loosely coupled with the application specific data structures itself. 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 - making it much easier to test any M, V, C layers. Current implementation -- A hack for javascript hack for Django admin app was releasing under WTFPL license: http://www.djangosnippets.org/snippets/1358/ It is useful with model-inheritance or metaclasses. This component should not require metaclasses or validator-wrapper inheritance, but would make it possible. Component integration = eZ Components already provides libraries that are useful for implementing a `Software Framework`_. 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. A repository implementation could be provided, coupling phpillow_, a CouchDB DBAL. Design requirements === - A data structure definition coded with the Validator component should not require loading any library other than the Validator compnonent and user defined classes (no UI_, ORM_, DBAL_, MVC_ implementations ...). - Structured data should contain their own definitions. - Support for two-way development: reverse engineer existing storage data structures. - Never require data structure change propagation: let the user concentrate on his application specific `Software Framework`_. - Support for client (PHP) side state full constraints (validator mutation). - Data structure validation, diff. - Support for data structure validators encapsulation: validator wrapping. - Support for validators agregating and inheritance. - Support for data structures creation on-the-fly. - Support for multiple storage models: - Provide a fixture generator. - RDBMS_ - eZPublish_ - CouchDB_ Special Considerations == 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. 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:
