|
[ Pobierz całość w formacie PDF ]
.Butfor the greatest value, more general events are best, so the information passed shouldbe easily created by a range of possible components, including those that have notyet been written, and not contain anything that is not general.[ 149 ] Handling ExtensionsSome actual triggers that can be built in to the CMS framework relate to login; wherealternative authentication schemes can be implemeneted.Another suitable eventfor a trigger is the sending of HTTP headers.And a WYSIWYG editor is most easilyinvoked as a plug in.Extension ParametersIt is helpful if the framework provides a basic yet flexible mechanism for handlingparameters.It can be used both by the framework and by extensions.There are twoaspects to a generalized parameter system: the definition of what parameters areto be used and the storage of actual parameter values.To implement parameterdefinitions it makes sense to use some scheme that is well supported by PHP.Although there are other possibilities, XML is a widely supported standard forstructured data, and PHP has good support for XML, especially in version 5.It isnow quite easy to read and validate XML, extracting the data into a usable form.It therefore makes good sense to use XML for packaging extensions and to holdinformation about the structure of sets of parameters.An optional part of the packaging XML is the section, which specifiesparameters that can be set by an administrator.The XML is sufficient for the CMSframework to be able to create the user interface for parameter updating, and caninclude the setting of defaults.Actual data provided by an administrator is stored inthe framework's database table for the appropriate kind of extension.There are two main ways in which parameters can be used.One is simply to makeextensions more flexible by allowing configuration by an administrator.The other isto support multiple instances of an extension, so that the same code can be used towork in different ways, according to what parameters are set.Currently, the use of multiple instances of an extension applies only to modules.Components are assumed to provide a more extensive administrator interface,typically more complex than could be achieved through a simple parameter system.Implementing components multiple times with different parameters is possible inprinciple.The other kinds of extensions, plug ins, and templates could also gainfrom the possibility of parameterization.At the time of writing, all these features areunder further development.[ 150 ] Chapter 7Framework SolutionThere are two main aspects to implementing extensions.One is the definition ofinterfaces, and the outline structure required of each type of extension.The otherarises if the CMS provides for easy installation of extensions, in which case the wayin which extensions are packaged has to be defined.Also, the framework has toinclude an installer.Detailed description of the mechanisms of the Aliro installer would take up too muchspace to include here.The design is described along with some code examples.Also,the ideas behind extension packaging are described, and a definition of the requiredXML file is provided in Appendix A.As the information provided in packagingis helpful in understanding extension mechanisms, packaging and installation aredescribed before the interfaces and structures for the various extensions.In a full Aliro implementation, every extension consists entirely of classes.Anextension must have at least one class, but may have others if the designer thinksit appropriate.For backwards compatibility with the Mambo family of systems,components can be implemented without using classes, but this runs counter to thedesign principles I am advocating and should be seen as a transitional situation.Other extension types being much simpler in structure are required to be one ormore classes by Aliro.Adapting older extensions to meet this requirement is usuallyquick, and simple.Creating extensions as classes is made easier and more effectiveby the Aliro automatic class loading mechanism described earlier, in Chapter 3.Modules, components, and plug ins are discussed here; further discussion oftemplates is left for later chapters.Please note that although the architecture of thecode follows the principles discussed above concerning modules, boxes, and blocksthe actual names used in the code refer mostly to modules.This is something thatshould be changed to improve clarity, but the number of alterations required meansthat it will take some time for the work to be done.Packaging ExtensionsTo make the management of a site easier, extensions can be packaged in such a waythat they can be installed into the CMS as a single file, using a standard installeravailable to the site administrator.Since an extension will always have more thanone file, the obvious way to do this is for the package to be an archive, such as zip ortar.gz.To guide the installation process, the package includes at least one XML filethat provides details about the extension [ Pobierz całość w formacie PDF ] |
Archiwum
|