Classes

The present chapter explains important classes of the frameworks and defines the intent. It goes into the internal design of the frameworks and the document object model (DOM) defined there. The class definitions are avaliable under API documentation in CHM files or ZIP files with plain HTML files.


1. Central basic classes of the framework

All classes in the folder "core" are important classes to the framework. These were structured in the folder "core", because the author assumes that these are necessary for building an application based on this framework. The following chapters discuss the most important and most often used classes and their intent.


1.1. APFObject

The class APFObject forms the very central class. Normally every class inherits from this base class. It defines attributes and methodes used in concrete implementations of this interface. APFObject is not only a base class to presentation layer classes but also to classes that are residing in the business or data layer. This has the advantage that many parts of the applications can be standardised. The private attributes define basic qualities of an object and allow object trees to be based by father-to-child relations. With the public methods the attributes and properties can be manipulated. The private methods are service methods which apply in the implementings of APFObject(). Examples for existing service methodes can be found on the configuration page.


1.2. Document

Document inherits from APFObject and plays a central role for presentation layer classes only. This class features a variety of parser methodes that generate object trees out of XML code and generates HTML code out of an given object tree with help of the transform() method. Every XML taglib must inherit from the Document class to be able to use it's attributes and methodes. The UML diagram can be seen under API dokumentation The developer does not get into contact with the class Document within template construction at first, nevertheless, the definition of the class will get interesting with the construction of own taglibs, because all tree nodes must inherit from Document to specialize the functionality of the tag.


1.3. Page

The class Page encases a complete web page with it's internal tree structure. It finds use in the index files and implements a variety of methods for the URL rewriting feature.


1.4. base_controller

The class base_controller is the central interface for all DocumentController according to the MVC approach. It describes which methods of the DocumentController must be implemented and which attributes of a Documents are available within the controller. Further details to controllers can be read up here. To insert dynamic contents in documents the method "transformContent()" must be implemented in the derived controller classes. It is executed while transforming a tree node and the content is afterwards implanted in the contents of the node. Thus it is possible, for example, to print out the text "hello world!" with respect to the browser language.


1.5. Singleton

A very often used component is the singleton implementation. The implementation contained in the framework is an abstract singleton class. With this it is possible to generate any class as a singleton object in the application. A requirement is that the constructor expects no duty parameters. For design and performance reasons nearly all services are used in "singleton" style. This means that "services" that used during a requests exist exactly once. This pattern is mainly used for all the services generated with the __getServiceObject() and __getAndInitServiceObject() methods. An often appearing application case of singleton is the benchmarker.


1.6. BenchmarkTimer

The BenchmarkTimer is other important component. With this it is possible to gather the execution times of different parts of the software and to generate a report from it. Thus performance-weak points can be found out and execution times be measured. Details to BenchmarkTimer can be read up here.


2. DOM object model of the presentation layer

With the contained page controller the framework owns a GUI controller who abstracts the complete GUI of a site into an own internal document object tree. Besides, every node is represented by an object which inherits from the class Document. Thus it is made sure according to the composite pattern that the object tree can be extended at any place. One single tree element is represented by a view and a controller concerning the MVC pattern. The model - here one speaks of "model" in terms of internals like expiries and status information, not from "model" for the purposes of a domain object - often is included in the controller, a business component or an extra model class. The view is represented by a template file in the present implementation and the controller is a DocumentController, inheriting from the class base_controller.

The page controller features the central parser methode __extractTagLibTags() which is used to create tree nodes (child nodes of the current node) by parsing known tags in template files. The functionality of a single DOM node is represented by a taglib class that inherits from the Document class. Each node has a set of known taglibs, that can be expanded by adding specific XML tags to a given template file. The documentation of these taglibs can be found on the Standard taglibs page.

If one analyzes the templates and controllers of the topical documentation web page, the following internal DOM object structure arises after the parsing of the templates:

Adventure php framework DOM object tree

The DOM definition of the frameworks assumes from the fact that the structure of a site is encapsulated in an object of the class Page. That means that the object of the class Page forms the root node. Within this root node a initial Document node is created to load the initial template. The known tags of this template are examined by the page controller and new child nodes are created from them.

In general, <core:importdesign /> tags are used to include the templates defined with the tag's attributes as a new child node in the existing DOM structure. Doing so, is possible to generate and to administer an arbitrarily deep tree structure. This is handy particularly in big web pages with meny views. Details on the <core:importdesign /> tag can be taken from the Standard taglibs page.


Comments

Do you want to add a comment to the article above, or do you want to post additional hints? So please click here. Comments already posted can be found below.
There are no comments belonging to this article.