On Sun, Dec 21, 2008 at 5:46 PM, James PIC <james...@gmail.com> wrote:
> Don't we also need some constraint definition feature? Thinking of this > after adding the Nth hundred line of custom Javascript UI mutation. > Added in "Design Requirements", thanks james! Also: spelling check. 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 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. 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 loosly 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 even when the quote was accepted anyway... 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: - DatabaseSchema_ provides complete information about fields, - PersistentObject_ provides complete information about objects and relations. Three solutions are possible: - 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 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. 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. 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. 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 ====================== .. _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 .. 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
