Plugin architecture
The idea behind this architecture is to allow the usage of different, specific code but have a common understanding. So it's not fare to use object orientation, so called "OO". PHP5 has major OO-featues but nearly no hoster runs this; PHP4 has only limited OO featues - hopefully enough for this task - but is used widely.
The common Plugin class behaves like a (java) bean - it has an empty constructor (without any values), an init function with nearly unspecified parameters and a function that will be called when the plugin is shut down.
But in this case each plugin needs some specific settings - which have to be setup in a nice and userfriendly way. So an additional function has been introduced. It's called getSetupHtml() without parameters and it has to return some html code that allows the user to set the values for this plugin.
For example the crawler plugin developed by enarion.net allows the user to set the url where it should begin to crawl and some other values; so this returns html-input entries with the apropriate userfriendly description around. This code will be embeded by the gui code of phpSitemapNG in a formular. To extract this specific plugin setup values and allow to return them to the plugin when necessary the formular elements have to be named a specified way, see the documentation for the getSetupHtml() function at the next page.
This setting values will now be internally stored by phpSitemapNG - to allow the user to change this settings and this also makes it possible to run the plugin with this settings without user input. The "genius" with this idea is that the plugin settings are used transparent to the plugin - they're stored somewhere and used whenever necessary - the plugin itself doesn't get to know in what context it's used.
The next page contains some information about the functions of the phpSitemapNG plugin class that have to be implemented by each plugin and afterwards an step by step example how to write your own phpSitemapNG plugin.
The common Plugin class behaves like a (java) bean - it has an empty constructor (without any values), an init function with nearly unspecified parameters and a function that will be called when the plugin is shut down.
But in this case each plugin needs some specific settings - which have to be setup in a nice and userfriendly way. So an additional function has been introduced. It's called getSetupHtml() without parameters and it has to return some html code that allows the user to set the values for this plugin.
For example the crawler plugin developed by enarion.net allows the user to set the url where it should begin to crawl and some other values; so this returns html-input entries with the apropriate userfriendly description around. This code will be embeded by the gui code of phpSitemapNG in a formular. To extract this specific plugin setup values and allow to return them to the plugin when necessary the formular elements have to be named a specified way, see the documentation for the getSetupHtml() function at the next page.
This setting values will now be internally stored by phpSitemapNG - to allow the user to change this settings and this also makes it possible to run the plugin with this settings without user input. The "genius" with this idea is that the plugin settings are used transparent to the plugin - they're stored somewhere and used whenever necessary - the plugin itself doesn't get to know in what context it's used.
The next page contains some information about the functions of the phpSitemapNG plugin class that have to be implemented by each plugin and afterwards an step by step example how to write your own phpSitemapNG plugin.
