MVC Framework/lib div Beta Branch
notice - Note
lib Class Diagram (draft)
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.