This module along with the plugin module implement the component architechture. We expect that most of the logic written using pluggdapps will, one way or the other, be organised as plugins implementing one or more interface(s). This module,
The platform is instantiated by calling the Pluggdapps.boot() method.
Pre-boot and boot
Pluggdapps component system is always instantiated in the context of a platform defined by Pluggdapps class or by classes deriving from Pluggdapps.
Platform boots in two phase, first there is a pre-boot which more or less does every thing that is done during an actual boot and then the actual booting. Pre-booting is designed such a way that other pluggdapps-packages can take part in platform booting, such as loading dynamic plugins, pre-compiling template scripts etc ...
So here is what happens duing pre-booting,
Pre-booting comes to an end by a call to pluggdapps.callpackages() function, which in turn is responsible for re-loading pluggdapps packages and calling the package entry-point. Note that package re-loading is handle in the context of a plain vanilla platform instantiated during pre-boot phase.
During the actual boot phase, everything that was done in pre-booting phase is repeated. But the entire blue-print of interfaces and plugins from all the installed packages will be remembered in the context of, probably a more sophisticated Webapps, platform class. The choice of platform class depends on how the user started pluggdapps.
Like mentioned before, platform classes are responsible for handling configuration.
default configuration,
All plugins deriving from pluggdapps.plugin.Plugin class, which is how plugins are authored, will automatically implement ISettings interface. And configurable plugins must override ISettings interface methods. Refer to pluggdapps.plugin.ISettings interface to learn more about their interface methods. When platform is booted, default_settings from loaded plugins will be gathered and remembered.
ini file,
Platform is typically booted by supplying an ini-file regarded as master configuration file. Settings in this master configuration file will override package default settings for plugins and other special sections. Configuration sections not prefixed with plugin: is considered as special section which are explained further below.
Master configuration file can refer to other configuration file.
An example master configuration file,
1 2 3 4 5 6 7 8 9 10 11 12 13 | [DEFAULT]
<option> = <value>
... = ...
[pluggdapps]
<option> = <value>
... = ...
[plugin:<pkgname>.<pluginname>]
<option> = <value>
... = ...
[...]
|
[DEFAULT] special section. Settings from this section is applicable to all configuration sections including plugins and referred configuration files. Semantic meaning of [DEFAULT] section is same as described by configparser module from python stdlib.
[pluggdapps] special section. Settings from this section is applicable to pluggdapps platform typically handled by Pluggdapps.
[mountloc] special section. Specific to web-framework (explained below) that is built on top of pluggdapps’ component system. Provides configuration settings on how to mount web-applications on web-url. Handled by Webapps platform class.
To learn more about backend store for configuration settings refer to module, pluggdapps.config.
Implemented by Webapps class (which derives from base platform class Pluggdapps), it can host any number web-application, and/or instance of same web-application in single python environment. Every web-application is a plugin implementing pluggdapps.interfaces.IWebApp interface. Like mentioned above every plugin gets instantiated in the context of a platform, and in this case, when plugins are instantiated by IWebApp plugin, either directly or indirectly, the instantiated plugins are automatically supplied with .webapp attribute which is now part of its context.
[mountloc] section and application wise ini file,
Web-applications can be mounted, hosted, on a netlocation and script-path (collectively called as netpath). This is configured under [mountloc] special section. While mounting web-applications under [mountloc] additional configuration files can be referred. Example [mountloc] section,
1 2 3 4 | [mountloc]
pluggdapps.com/issues = <appname>, <ini-file>
tayra.pluggdapps.com/issues = <appname>, <ini-file>
tayra.pluggdapps.com/source = <appname>, <ini-file>
|
The lhs side is called netpath which typically contains subdomain, hostname and scripth-path. The rhs side is a tuple of two elements. First is the name of a IWebApp plugin and second is path to application configuration file.
Referred configuration files are exclusive to the scope of the mounted application, and shall not contain any special sections, except [DEFAULT], unless otherwise explicitly mentioned. When a plugin is instantiated in the context of a web-application, configuration settings from application-ini-file will override settings from the master-ini-file.
Bases: builtins.object
Platform class tying together pluggdapps platform, component architecture and configuration system. Do not instantiate this class directly, instead use the boot() method call (which is a classmethod) to start the platform.
Master Configuration file, absolute location.
Default settings for plugins, gathered from plugin-default settings, master configuration file and other backend stores, if any.
pluggdapps.interfaces.IConfigDB plugin instance.
Boot the platform using master configuration file baseini. Return a new instance of this class object. This is the only way to create a platform instance.
Call back function during plugin instantiation, from pluggdapps.plugin.PluginMeta class.
Get or set configuration parameter for the platform. If no keyword arguments are supplied, will return platform-settings. This API is meant applications who wish to admister the platform configuration.
Keyword arguments,
Use this API to query for plugins using the interface class it implements. Positional and keyword arguments will be used to instantiate the plugin object.
If settings key-word argument is present, it will be used to override default plugin settings. Returns a list of plugin instance implementing interface
Use this API to query for plugins using the interface class it implements. Positional and keyword arguments will be used to instantiate the plugin object.
If settings key-word argument is present, it will be used to override default plugin settings. Returns a list of plugin instance implementing interface
Same as queryPlugins, but returns a single plugin instance as opposed an entire list. name will be used to identify that plugin. Positional and keyword arguments will be used to instantiate the plugin object.
If settings key-word argument is present, it will be used to override default plugin settings. Return a single Plugin instance.
Use this method to log informational messages. The log messages will be formated and handled based on the configuration settings from [pluggdapps] section.
Use this method to log debug messages. The log messages will be formated and handled based on the configuration settings from [pluggdapps] section.
Bases: pluggdapps.platform.Pluggdapps
Provides a web-framework based on a pluggable MVC design pattern. Can mount any number of web-application in the same python environment.
Dictionay mapping of mount-key and pluggdapps.web.webapp.WebApp instance, where mount-key is a tuple of appsec, netpath, application-ini
Dictionay mapping of netpath, and pluggdapps.web.webapp.WebApp instance.
A dictionary map of webapp’s instkey and its base-url. The base url consists of scheme, netloc, scriptname.
Parse [mountloc] section for application-wise configuration settings and return a fresh instance of Webapps class.
Boot all loaded application. Web applicationss are loaded when the system is booted via boot() call. Apps are booted only when an explicit call is made to this method.
Call back function during plugin instantiation, from pluggdapps.plugin.PluginMeta class.
Get or set configuration parameter for the platform. If no keyword arguments are present, will return a dictionary of webapp-settings, where each webapp is identified by netpath as key.
Keyword arguments,
Use this API to query for plugins using the interface class it implements. Positional and keyword arguments will be used to instantiate the plugin object.
If settings key-word argument is present, it will be used to override default plugin settings. Returns a list of plugin instance implementing interface
Use this API to query for plugins using the interface class it implements. Positional and keyword arguments will be used to instantiate the plugin object.
If settings key-word argument is present, it will be used to override default plugin settings. Returns a list of plugin instance implementing interface
Same as queryPlugins, but returns a single plugin instance as opposed an entire list. name will be used to identify that plugin. Positional and keyword arguments will be used to instantiate the plugin object.
If settings key-word argument is present, it will be used to override default plugin settings. Return a single Plugin instance.