MVC Framework/lib div Beta Branch

notice - Note

The lib/div extensions are not actively maintained and should be considered deprecated!!

lib Class Diagram (draft)

This page belongs to the Extension coordination team (category ECT)

This page belongs to the MVC Framework aka lib/div project (category Project)

lib Directory (draft)

The naming style is using the PEAR-Coding Guidelines in the first draft. We should probably use v5 style instead.

 Interfaces/Controller.php

would become

 Interfaces/tx_Lib_Interfaces_Controller.php

Right??? Please see v5 Coding Guidelines. When this has beed decided this page should be adapted accordingly.

 Register.php         (multipurpose register, singleton storage (a Design Pattern))
 Object.php           (multipurpose data structure)

 Request.php          (static access to request parameters)
 FlexForm.php         (static access to FF)
 Setup.php            (static access to $configurations (TS))
 SetupPlus.php        (static access to TS < FF overwrite)
 TCA.php              (static access to TCA)
 TCAPlus.php          (static access to TCA < TS < FF overwrite, for model and form generation)

 Interfaces/                                  (interface definitions)
 Interfaces/Controller.php
 Interfaces/Processor.php
 Interfaces/Service.php

 Abstracts/                                   (abstract classes)
 Abstracts/ConfigurationAccess.php
 Abstracts/Object.php
 Abstracts/Processor.php
 Abstracts/SelfAwareness.php

 Controllers/SwitchingController.php          (meta controller with FF subcontroller selector)
 Controllers/StandardController.php           (actions as methods)
 Controllers/ActionObjectController.php       (actions as object)

 Processors/                                  (processors of the action pipe)
 Processors/Session.php
 Processors/Request.php
 Processors/Translator.php
 Processors/Transformer.php
 Processors/Highlighter.php
 Processors/PHPView.php
 Processors/SmartyView.php
 Processors/ResultBrowser.php                 (MVC Framework/ResultBrowser)

Helpers is the folder for all the rest. An alternative would be Library. But tx_Lib_Library_Something sounds strange.

 Helpers/Link.php                             (library)
 Helpers/Image.php 
 Helpers/Transformations.php 

The result browser shows how widgets have to be designed. Captcha and validator should be implemented as widgets in beta. The error messages are the view part of the validator. Counter is just a fictive widget here.

 Widgets/Captcha/Model.php
 Widgets/Captcha/View.php
 Widgets/Captcha/Controller.php
 Widgets/Counter/Model.php
 Widgets/Counter/View.php
 Widgets/Counter/Controller.php
 Widgets/ResultBrowser/Model.php              (MVC Framework/ResultBrowser)
 Widgets/ResultBrowser/View.php
 Widgets/ResultBrowser/Controller.php
 Widgets/Validator/Model.php
 Widgets/Validator/View.php
 Widgets/Validator/Controller.php

We still need to research how interfaces for lib/div should look like. The calendar project is currently working on a "general service" for cal.

 Services/                                    (service like access to helpers)
 Services/ResultBrowser.php

Redesign of the view

The view classes currently do 2 different tasks at once:

a) They transform the data.
b) They render the template.

This has disadvantages.

a) The view is complex.
b) The class hierarchy of the view is complex.
c) The view doesn't fit well into the philosophy of a chain of processors.
d) It's not that trivial to exchange rendering engines.

Solution

Transformer and renderer should be decoupled into separate processors. The transoformer methods will be stored into the helper class transformer.

The transformer processor(s) use that helper. There should be at least two transformer processors, one to transform model data to view (ModelToViewTransformer), one to transform form parameters to model data (ParametersToModelTransformer). A third transformer processor (ParametersToFormTransformer) may be considered for the redisplay of form data in the view (htmlspecialchars).

The view becomes a simple rendering processor by now, that does no transformations at all. This approach also makes it possible to use a simple common API for different types of rendering engines.

How can we reduce levels of inheritence?

Hint: In the following examples I use the naming style of the alpha branch.

Moving SPL onto the top the current hierarchy would look similar to this:

 SPL > tx_lib_SelfAwareness > tx_lib_objectAbstract > tx_lib_object > tx_lib_processor > tx_lib_resultBrowserProcessor

How could this be flattened?

Option 1

Inheritance of the abstract processor from the abstract object (data):

... > tx_lib_objectAbstract                            > tx_lib_dataObject
... > tx_lib_objectAbstract                            > tx_lib_myObject
... > tx_lib_objectAbstract > tx_lib_processorAbstract > tx_lib_resultBrowserProcessor

Option 2

Merging of the abstract processor and the abstract data:

... > tx_lib_objectAbstract > tx_lib_dataObject
... > tx_lib_objectAbstract > tx_lib_myObject
... > tx_lib_objectAbstract > tx_lib_resultBrowserProcessor

• Advantage: Hierarchy is more simple.
• Disadvantage: Data objects contain the processor methods setStatus() and getStatus().

Option 3

Implementation of a processor interface instead instead of inheriting the processor methods.

class tx_lib_resultBrowserProcessor extends tx_lib_objectAbstract implements tx_lib_processorInterface { ... }

• Advantage: Hierarchy is as simple as in option 2.
• Advantage: Data objects don't contain processor methods.
• Disadvantage: Each processor needs to implement the processor interface.

Option 4

Removing the selfAwareness level from the ancesters and using an external static class (consultant) to query the data.

* $designator = $this->getDefaultDesignator();
* $designator = tx_lib_consultant::tellMyDefaultDesignator();

• Advantage: Flattened hierarhy.
• Disadvantage: Separation of data and methods, because $this->defaultDesignator keeps a property of tx_lib_objectAbstract.
• Disadvantage: Unusual use of objects. More stuff to explain and understand.

Option 5 (preferred)

Merging tx_lib_selfAwareness and tx_lib_objectBase into a single tx_lib_objectAbstract.

ArrayIterator > tx_lib_objectAbstract > tx_lib_dataObject
ArrayIterator > tx_lib_objectAbstract > tx_lib_myObject
ArrayIterator > tx_lib_objectAbstract > tx_lib_processorAbstract > tx_lib_resultBrowserProcessor

With direct inheritency from the build in ArrayIterator(PHP5) many of the current methods of tx_lib_objectBase will drop. The merged class will not become a giant.