[TYPO3-50-general] [TYPO3-ect] RFC: lib will become cool

Elmar Hinz elmar07 at googlemail.com
Tue Oct 9 09:29:07 CEST 2007


This is a crossposting! Please answer to ECT.

After collecting all the experiencies and suggestions of the ECT list I
melted them now into a full concept for the beta branch. I ask for your

I start using the beginnings of Joerg, in special the loader. The beta
branch will get new key: cool. 

"Cool" means "Coordinated object library".

The main reason for this switch of the key is, the problem, that you can't
use different version of the same library in parallel. As the API will be
different, it would be a problem to run alpha based projects in parallel
with the beta ones. Apart from that, I think "cool" is a cooler name for a
library. I also tested, that "cool" is nearly as quickly to type as lib.

Lib will be maintained for a while and soon will be moved to beta. 

Principles of the architecture:

1.) The singleton objects (the object mesh) will stay in a small container
(tx_cool_Factory) controlled by a main builder object (tx_cool_Main). That
means that most extensions will call the same class (tx_cool_Main), unless
you extend or replace it:

lib.xyz = USER(_INT)
lib.xyz.user_Func = tx_cool_Main->main
lib.xyz.setup < temp.xyz.configurations
lib.xyz.mesh { 
 Factory = tx_cool_Factory
 Controller = tx_cool_Controller
 LocalTSValues = tx_cool_LocalTSValues

2.) The object mesh is completly configurable by the TS mesh array. This is
similar to the underlying concept of JAVA Spring.

3.) The setup array works like the configurations of lib. The object
tx_cool_Setup will give access to the merger of tx_cool_LocalTSValues and

4.) The naming style follows Roberts suggestions (tx_cool_FFValues). It's
compatible with the extension manager. There are no ugly warnings. You can
use your own style by adding a different loader.

5.) The container (tx_cool_Factory) instantiates (finds) the objects on
demand. For example tx_cool_TCAValues will only be created when requested. 

6.) The container/factory itself works generic and can deliver any object
configured in the mesh setup. However there will be typical setters and
getters for the basic mesh objects, to support the usage of IDEs. 

7.) The hardcoded access to environment variables like the global TS,
Parameters etc. will not be part of the container or of the configuration
access objects. It will be concentrated into one place, the main object.

8.) For objects, that are allways needed (Controller, LocalTSValues)
the "injection of dependency" pattern will have preference to the "factory
pattern" (find on demand). Objects will have IDE visible setters this way.
Unit testing and reusibility is enhanced. It's the job of the main builder
to setup this mesh of objects controlled by the TS mesh setup.

9.) The tx_cool extension will mainly focus on this controller stuff.
Features, views and models can be contributed as addon extensions by the
team. Addons are marked by a double underscore.

tx_cool__pop, tx_cool__smarty, tx_cool__pdf, tx_cool__dao, ...

10.) In the controller there is not a strict pair of model and view required
like in JAVA Spring or JAVA Struts. It's up to the developers choice, how
she organizes the controller. Objects to build a pipeline of processors
(PoP) will be shipped with the tx_cool__pop addon.

11.) Static methods will be avoided inside the library itself, becase they
hinder unit testing and exchangablility of classes. For users of the
library, that prefer direct static access to configurations, the necessary
static methods will be provided.

12.) To support static access with the PAC pattern (Hierarchical MVC), a
solution like a stack of the container object is required. The static
methods should always access the configuration of the current node.


13.) The PAC pattern (HMVC) is supported by setters for configuration
objects from parent to childs. 

14.) The API will be hardened by unit tests shipping with.

15.) Needless to say that PHP5 is required.



More information about the TYPO3-project-5_0-general mailing list