After Gaetano's relevant input, i removed the part about Java which turned out to be off-topic and added two design requirements and spelling fix. Not committing in experimental repo until the component is accepted or i am explicitly granted the permission to do so.
Thanks again Gaetano! I appreciated the reply a Saturday ;) Regards, James. eZ Component: FrameworkTools, 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 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. Note that if you don't understand a term, you should have a look at the section `Clarification of terms`_. Introduction ============ The goal of FrameworkTols component is to give users a basis for such architectures for web 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 easily usable. There are two ways to develop a SoftwareFramework_. Way 0: Develop and factorize ---------------------------- Develop an application, factorize into re-usable libraries (Django). In this case, power users can be rapidly confronted to limitations such as lack of factorization, and the need to either: - do the decoupling himself and patch the framework, maintain his branch until the patches are accepted upstream, if ever. - re-invent what is already implemented in a "contrib" application. The need for BC break is also encountered when updating the framework with this kind of process. FrameworkTools should make it possible for the user to maintain a framework without causing any BC breaks. Way 1: Study needs and implement -------------------------------- A correct study of the needs allow to implement the SoftwareFramework_ with proper object-oriented design in the first place. There should not be any factorisation left to do, BC breaks are then optional. The need -------- 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 only allows it to implement it properly, without coupling UI, ORM/DBAL ... 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 most 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 anyway! 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: - DatabaseSchema_ provides complete in formations about fields, - PersistentObject_ provides complete in formations about objects and relations. Three solutions are possible: - Embed the fields in formations in PersistentObject_, deriving from its original requirements, making it able to replace DatabaseSchema_ with high overhead. - Embed the relations in formations 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_. 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: - 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 FrameworkTools 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. 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 specificities: 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. 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 ...). Special Considerations ====================== Data structure definitions should be realizable and with an exportable state: to save data structures in a database instead of some configuration file. This can be usefull for eZ Publish. 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 ====================== .. _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 .. _SoftwareFramemork: http://en.wikipedia.org/wiki/Software_Framework -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
