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

Reply via email to