nti.site.hostpolicy module

Support for host policies.

This contains the main unique functionality for this package.


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 by zope.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
   dataserver2         -> /Application/dataserver2
   nti.dataserver      -> /Application/dataserver2
   nti.dataserver_root -> /Application


Passing in duplicate names for any of the parameters may result in unexpected results.


The aliases are only installed if the alias parameters are true. In the future, the alias parameters will default to false.


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.

  • 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().


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.


While already operating inside of a transaction and the application environment, execute the callable given by func once for each persistent, registered host (see synchronize_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.

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.