|
wCMF
3.6
|
|
wCMF
3.6
|
The framework offers developers the following main points of extension
Since the support of a persistence mechanism affects the loading, storing and deleting of domain objects, corresponding PersistenceMapper subclasses have to be defined. The storing of application data in a text file for instance requires a FileMapper for each domain class, which is able to load, delete and alter objects in a text file.
Adding new domain classes first of all requires their definition in the persistence mechanism (name, attributes, contained domain classes). In a relational database this usually is achieved by one table per domain class and if necessary additional connection tables, which reflect the relations between the objects. In the next step a corresponding PersistenceMapper has to be implemented, which makes the access to the data and the construction of the accompanying domain object possible.
If the Node class isn't sufficient for the data representation, a new domain class finally has to be defined (for details see Definition of the data model).
The output formats, in which the application data is transformed, can be defined via an OutputStrategy. This strategy may be applied for example by using an OutputVisitor, to which the new format is made accessible by its method OutputVisitor::setOutputStrategy.
If large amounts of data have to be exported, alternatively one of the subclasses of BatchController can be used, since these allow the splitting of long tasks into packages, which can be handled over multiple page calls. This is useful for example when exporting static HTML pages from a CMS.
For defining the user interaction in the simplest case solely one configuration file is needed, which establishes an order of controllers for certain actions. By that a controller for a complex action can be defined through the combination of primitive controllers (e.g. a MoveItemController from an InsertItemController and a DeleteItemController). If new actions should be added, a new controller has to be implemented (for details see Programming the application).
Another way to vary the user interaction is given through the modification of the views, which means the modification of the form and link definitions in the templates. By defining different contexts it is also possible to assign different views to a controller while maintaining the same action (e.g. to display an input form for data in one context and the preview of the same data in another).
The application's appearance is completely described by the views. Since these themselves are defined in corresponding Smarty templates, modifying the templates makes it quite easy to fit the layout to the special needs of the application.
Data sent to the framework and received from the framework is transported in Request and Response instances. The data is interpreted using an IFormat implementation. This allows to easily implement new data exchange formats. Already supported formats are HTML (HTMLFormat), JSON (JSONFormat) and SOAP (SOAPFormat).
Back to the Overview | Previous section Architecture | Next section Configuration
1.8.6 
