nti.site.hostpolicy module¶
Support for host policies.
This contains the main unique functionality for this package.
-
nti.site.hostpolicy.
get_all_host_sites
()[source]¶ The order in which sites are accessed is top-down breadth-first, that is, the shallowest to the deepest nested sites. This allows you to assume that your parent sites have already been updated.
Returns: A list of sites Return type: list
-
nti.site.hostpolicy.
get_host_site
(site_name, safe=False)[source]¶ Find the persistent site named site_name and return it.
Parameters: safe (bool) – If True, silently ignore any errors. DO NOT use this param. Deprecated and dangerous.
-
nti.site.hostpolicy.
get_site
(site_name, safe=False)¶ Find the persistent site named site_name and return it.
Parameters: safe (bool) – If True, silently ignore any errors. DO NOT use this param. Deprecated and dangerous.
-
nti.site.hostpolicy.
install_main_application_and_sites
(conn, root_name=<u'Application' is the default root folder>, root_alias=<u'nti.dataserver_root' is the default alias of root folder>, main_name=<u'dataserver2' is the default main application folder>, main_alias=<u'nti.dataserver' is the default alias of main application folder>, main_factory=<class 'zope.site.folder.Folder'>, main_setup=None)[source]¶ Install the main application and site folder structure into ZODB.
When this completes, the ZODB root object will have a
IRootFolder
object at root_name (and optionally at root_alias), created byzope.site.folder.rootFolder()
. This will have a site manager. Note that this object does not have a__name__
and will serve as the base (root, or “/”) for object path traversal.The root folder in turn will have a
IMainApplicationFolder
child named main_name (and optionally at main_alias). It will have a site manager, and in this site manager will be the “++etc++hostsites” object used to contain host site folders.The tree will look like this:
<Connection Root Dictionary> <ISite,IRootFolder>: root_name rootFolder() <ISite,IMainApplicationFolder>: main_name <main_factory> ++etc++hostsites <class 'nti.site.folder.HostSitesFolder'> main_name -> /root_name/main_name main_alias -> /root_name/main_name root_alias -> /root_name
Using the default names, that would be:
<Connection Root Dictionary> <ISite,IRootFolder>: Application <ISite,IMainApplicationFolder>: dataserver2 ++etc++hostsites dataserver2 -> /Application/dataserver2 nti.dataserver -> /Application/dataserver2 nti.dataserver_root -> /Application
Caution
Passing in duplicate names for any of the parameters may result in unexpected results.
Note
The aliases are only installed if the alias parameters are true. In the future, the alias parameters will default to false.
Note
The root folder
Changed in version 2.1: The root_alias now points to the root_name. Previously it pointed to main_name (e.g., /Application/dataserver2). This made no sense because main_alias already pointed there.
Parameters: - conn – The open ZODB connection.
- root_name (str) – The main name of the root folder. This generally should be left as “Application” as that’s what many Zope 3 components expect.
- main_factory – The factory that will be used for the
IMainApplicationFolder
. If it produces an object that doesn’t implement this interface, it will still be marked as doing so. - main_setup (callable) – If given, a callable that will accept the main
application folder object and perform further setup on it. This will be called
before any lifecycle events are generated. This is a good time to install additional
utilities, such as
IIntId
utilities.
After main_setup has been called, and the lifecycle events for the root folder and main folder have been generated, this calls
install_sites_folder()
.
-
nti.site.hostpolicy.
install_sites_folder
(server_folder)[source]¶ Given a
IMainApplicationFolder
that has a site manager, install a host sites folder.The folder will be installed at “++etc++hostsites”, and registered to provide
IEtcNamespace
with the name “hostsites” so it can be found by traversal.See also
zope.traversing.namespace.etc
.
-
nti.site.hostpolicy.
run_job_in_all_host_sites
(func)[source]¶ While already operating inside of a transaction and the application environment, execute the callable given by
func
once for each persistent, registered host (seesynchronize_host_policies()
). The callable is run with that site current.This is typically used to make configuration changes/adjustments to utilities local within each site, while the appropriate event listeners for the site also fire.
You are responsible for transaction management.
Raises: Whatever the callable raises. Returns: A list of pairs (site, result)
containing each site and the result of running the function in that site.Return type: list
-
nti.site.hostpolicy.
run_job_in_host_site
(site, func)[source]¶ Helper function to run the func with the given site as the current site.
Parameters: site – Either the site object itself, or its unique name.
-
nti.site.hostpolicy.
synchronize_host_policies
()[source]¶ Called within a transaction with a site being the current application site, find any
z3c.baseregistry
components that should be persistent sites, and register them in the database.As a prerequisite,
install_sites_folder()
must have been done, and we must be in that site.