Platform PT
Currently there is no genuine documentation available. We are going to cover relevant topics under this wiki space to create a documentation in the (hopefully not so distant) future.
The design concept
respice - platform PT is a very loose framework (some like the term "flexible") and is intended to
- improve rapid application development by suggesting a quasi-standard, mainly to
- allow larger groups to develop on different levels of abstraction and skill.
- learn, share and evolve.
The People
respice - platform PT is orginally written by Philpp Hunstein & Seong-Min Kang. They own a small web consulting/development company (http://www.respice.net). When they started working on the framework, they wanted to create a flexible environment to propel their own web services. Rapid development and scalability were the main goals.
File System Structure
build
|-loads of applications..
data
htdocs
inc
|-system
lib
|-application
|-db
|-handler
|-misc
|-exceptions
|-template
|-xml
maintenance
modules
|-loads of modules...
templates
text
License
respice - platform PT is published under the FreeBSD license, providing highest flexibility. This documentation is published under the GNU Free Documentation License.
Core
Patterns and Mechanics
SingletonPattern
Many of the modules and the lib classes are implemented as singletons. This means, these classes have a private constructor, and you need to call PWhateverClass::get(), to get the only one instance of the class. The first time you call get(), a new instance of the singleton will be created, stored in the hidden member variable PWhateverCLass::$_instance and returned. When you call get() again, it will return the stored variable, so the same object.
Sometimes the ::get() function is private itself, and instead the class provides static methods for all the functionality.
Singletons have some advantages compared to global variables:
- Helper methods and variables can be defined as private, which prevents use of these functions throughout the program.
- We can use getter and setter methods, to protect inner data from unlimited access.
Singletons receive a lot of criticism because they are not so different from global variables. This increases the dependency of components with each other, and makes unit testing more difficult.
PT/Rox Classes implemented as Singleton:
- PClasses
- other?
Singleton Registry Pattern
The PVars class implements the registry pattern, as a singleton. Everything that is stuffed into the PVars registry can be read from everywhere. This may appear convenient at first, but it introduces global dependencies, which makes the code harder to maintain.
Another possibility (recommended by OOP purists) would be to pass the registry object around as a function parameter, to reduce the global dependencies.
A lot more can be written here...
PClasses __autoload($className) controlled by XML files
The PClasses class uses the PHP function __autoload($className) to include php files (modules and applications) only when needed. In the PT implementation, we need to store XML files along with the modules and apps to tell PT which php files have to be loaded for which classname.
Single Entry Point
Our single entry point is the "htdocs/index.php". There the global variables (or better, registry entries) are initialized, and the request is analyzed.
Request Routing
In index.php the first part of the request string is analyzed, and one controller class is chosen. For instance, for the url "http://www.bewelcome.org/forums/new", we get the request "forums/new", the first part of that is "forums", which triggers the controller class "ForumsController?".
In the index() function of the respective controller, the request is further analysed, usually using a switch() statement, to determine which page to show, or which things should be written in the session or DB.
