Re: [Components] Proposal: FrameworkTools
After Gaetano's relevant input (off-mailing list), this is the new version. Thanks again Gaetano, not only for the revelance of your input but also for your support on a Sunday! Updates: - moved the eZ Publish db schema style from Special Considerations to Requirements list, - added some Requirements, - factorized and re-structured Introduction. Read below: 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 detailled 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 detailled 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 informations about fields, - PersistentObject_ provides complete informations about objects and relations. Three solutions are possible: - Embed the field informations in PersistentObject_, deriving from its original requirements, making it able to replace DatabaseSchema_ with high overhead. - Embed the relations informations 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:
Re: [Components] Proposal: FrameworkTools
Don't we also need some constraint definition feature? Thinking of this after adding the Nth hundred line of custom Javascript UI mutation. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Proposal: FrameworkTools
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:
