Page "Proposals/BEP-0003" was changed by olemis Diff URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diff&version=28> Revision 28 Comment: [BEP-0003] Sync with comment:7:ticket:115 Changes: -------8<------8<------8<------8<------8<------8<------8<------8<-------- Index: Proposals/BEP-0003 ========================================================================= --- Proposals/BEP-0003 (version: 27) +++ Proposals/BEP-0003 (version: 28) @@ -42,7 +42,7 @@ === Product extensions to the trac.env.Environment API #product-env-api -There is no need to create ''product environments'' explicitly via [TracAdmin trac-admin] commands. Provided that the target product exists in the database, they will be instantiated like shown in the following code snippet. The instance of `trac.env.Environment` representing the global environment will be accessed via `parent_env` attribute. The target product will be available in `product` attribute. +There is no need to create ''product environments'' explicitly via [TracAdmin trac-admin] commands. Provided that the target product exists in the database, they will be instantiated like shown in the following code snippet. The instance of `trac.env.Environment` representing the global environment will be accessed via `parent` attribute. The target product will be available in `product` attribute. {{{ #!py @@ -51,7 +51,7 @@ <trac.env.Environment object at 0x7faacb1e9490> >>> from multiproduct.env import ProductEnvironment >>> product_env = ProductEnvironment(env, product_prefix) ->>> product_env.parent_env +>>> product_env.parent <trac.env.Environment object at 0x7faacb1e9490> >>> product_env.product <multiproduct.model.Product object at 0x35566d0> @@ -96,30 +96,61 @@ }}} -''Product environments'' will implement both `trac.core.ComponentManager` and `trac.core.Component` APIs. As a consequence instances will have its own components cache, which means that every active component class will only have a single instance for every product environment. They will inherit most of the properties of the global `trac.env.Environment` by acting as wrappers often forwarding method calls to be handled by the parent global environment. - -The following list explains how product environments will adapt existing environment API while still being compatible with it. - - - '''[=#product-env-config] config''' will contain an - instance of `trac.config.Configuration` (or equivalent) setup in +''Product environments'' will implement both `trac.core.ComponentManager` and `trac.core.Component` APIs. As a consequence instances will have their own components cache, which means that every active component class will only have a single instance for every product environment. They will inherit most of the properties of the global `trac.env.Environment` by acting as wrappers often forwarding method calls to be handled by the parent global environment. + +[=#product-env-members] The following list explains how product environments will adapt existing environment API while still being compatible with it. + + - [=#product-env-config] '''config''' will contain an + instance of `multiproduct.config.Configuration` (or equivalent) setup in such a way that it reads product-specific - settings from a file located at path - `./conf/product_<product prefix>.ini` relative - to the global environment's directory and - inherits globals settings stored in - `./conf/trac.ini` file. Some exceptions needs to + settings from the database . It will inherit globals settings stored in + `./conf/trac.ini` file and relative paths will be resolved with respect + to `./conf` sub-folder. Some exceptions to common behavior need to be installed in place. * '''TODO''' - - '''[=#product-env-shared_plugins_dir] shared_plugins_dir''' will always be empty . There + - [=#product-env-shared_plugins_dir] '''shared_plugins_dir''' will always be empty . There will be no way to deploy plugins for a particular product, just enable/disable those installed in the global environment. - - '''[=#product-env-system_info_providers] system_info_providers''' will enumerate + - [=#product-env-system_info_providers] '''system_info_providers''' will enumerate components in the global environment implementing `ISystemInfoProvider`. - - '''[=#product-env-setup_participants] setup_participants''' will always be empty. - - '''TODO''' - -[=#product-env-idem] The following methods and options will behave exactly the same as the corresponding `parent_env`'s methods: ''get_system_info'' , ''components_section'' , '''TODO''' . + - [=#product-env-setup_participants] '''setup_participants''' will always be empty. + - [=#product-env-base_url] '''base_url''' '''TODO''' + - [=#product-env-base_url_for_redirect] '''base_url_for_redirect''' '''TODO''' + - [=#product-env-project_name] '''project_name''' will be the product name + - [=#product-env-project_description] '''project_description''' will be product description + - [=#product-env-project_url] '''project_url''' '''TODO''' + - [=#product-env-project_footer] '''project_footer''' '''TODO''' + - [=#product-env-project_icon] '''project_icon''' will be an option but will be read from + product-specific configuration, and thereby it will be possible to override equivalent + values configured for the global environment. + - [=#product-env-logging] '''log_type''', '''log_file''', '''log_level''', '''log_format''' + will be options but will be read from + product-specific configuration, and thereby it will be possible to override equivalent + values configured for the global environment. + - [=#product-env-log_file] will be an option but will be read from + product-specific configuration, and thereby it will be possible to override equivalent + values configured for the global environment. + - [=#product-env-is_component_enabled] '''is_component_enabled''' will be slightly different + due to [#components-env-setup environment setup constraints]. + - [=#product-env-needs_upgrade] '''needs_upgrade''' will only return `False` + due to [#components-env-setup environment setup constraints]. + - [=#product-env-upgrade] '''upgrade''' will only return `True` + due to [#components-env-setup environment setup constraints]. + - [=#product-env-get_repository] '''get_repository''' '''TODO''' + - [=#product-env-href] '''href''' '''TODO''' + - [=#product-env-abs_href] '''abs_href''' '''TODO''' + - [=#product-env-create] '''create''' will be an empty placeholder kept for the + only purpose of API compatibilty. + - [=#product-env-shutdown] '''shutdown''' will never jeopardize the availability of + neither sibling product environments nor the global environment. + - [=#product-env-db] '''get_db_cnx''', '''with_transaction''', '''get_read_db''', + '''db_query''', '''db_transaction''' will translate database access into product context. + - [=#product-env-idem] '''component_activated''', '''_component_name''', '''db_exc''', + '''_component_rules''', '''enable_component''', and '''get_known_users''' will be verbatim + copies of Trac's but will act upon product environment instance. + +[=#product-env-idem] Remaining members of `trac.env.Environment` will be returned by product environments too. === Product routes #routes @@ -241,7 +272,7 @@ }}} Product environments are meant to implement `trac.core.ComponentManager` API and inherit global plugins installations by design. Hence every component class will have a singleton instance for each product (besides the one for the global environment). Components are enabled/disabled via `[components]` section in configuration file. The fact that each product will have a [#config separate configuration file] also means that there will be one such section to enable/disable each class on a per product basis. -This situation is quite similar to what happens nowadays in multi-environment installations. The main difference will be that a component may be enabled for a given product only if it's been previously enabled for the global environment . This constraint is aimed at scoping environment setup tasks (e.g. database updgrades) in the context of the global environment. Product environments will not participate at all in this process so as to avoid some undesired side-effects . One of them is explained below . +[#components-env-setup] This situation is quite similar to what happens nowadays in multi-environment installations. The main difference will be that a component may be enabled for a given product only if it's been previously enabled for the global environment . This constraint is aimed at scoping environment setup tasks (e.g. database updgrades) in the context of the global environment. Product environments will not participate at all in this process so as to avoid some undesired side-effects . One of them is explained below . Let's suppose plugins may be enabled at will in both global environment and product environments. Initially environment state is steady . Component `C` is installed but it has never been enabled . It requires a database upgrade . Suddenly it's enabled for product `P1` . As a consequence environment upgrade should be applied (new tables, etc ...) . Such upgrade will only be possible if an instance of `C` announces that such changes must be carried out. However there will be no such setup participant neither in the global environment list nor any other product environment besides `P1` . Summarizing, allowing for such scattered differences may lead to @@ -266,9 +297,9 @@ }}} Product-specific settings will be implemented in #115 . -`trac.conf.Configuration` instance in [#product-env-config config attribute] of product environments will read settings from `product-<product prefix>.ini` file and will be configured to inherit settings in environments' `trac.ini` file. - -Even if the proposal only suggests ''ini files'' to store product-specific configuration it is also possible to think of using other configuration repositories (e.g. database, [http://hadoop.apache.org/hdfs/ HDFS], remote data repositories). It is a feasible enhancement though details have been omitted. +`trac.conf.Configuration` instance in [#product-env-config config attribute] of product environments will read settings from the database and will be configured to inherit settings in environments' `trac.ini` file. + +Even if the proposal only suggests one database backend to store product-specific configuration it is also possible to think of using other configuration repositories (e.g. ''ini files'' , [http://hadoop.apache.org/hdfs/ HDFS], remote data repositories). It is a feasible enhancement though details have been omitted. }}} The following requirements are a corollary , considering that such customizations are performed in the configuration file. @@ -285,7 +316,7 @@ Implementation notes }}} -Edit `[header-logo]` section in `product-<product prefix>.ini` file. +Edit `[header-logo]` section in [#config product settings table]. }}} ==== Per product ticket workflow #workflow @@ -300,7 +331,7 @@ Implementation notes }}} -Edit `[ticket-workflow]` section in `product-<product prefix>.ini` file. +Edit `[ticket-workflow]` section in [#config product settings table]. [TracWorkflow#AdvancedTicketWorkflowCustomization Advanced ticket workflow customization] will be possible for individual products since [#components components may be enabled/disabled on a per product basis]. @@ -318,7 +349,7 @@ Implementation notes }}} -Edit `[notification]` section in `product-<product prefix>.ini` file. +Edit `[notification]` section in [#config product settings table]. }}} @@ -334,7 +365,7 @@ Implementation notes }}} -Edit `[ticket-custom]` section in `product-<product prefix>.ini` file. +Edit `[ticket-custom]` section in [#config product settings table]. }}} -------8<------8<------8<------8<------8<------8<------8<------8<--------
-- Page URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003> Apache Bloodhound <https://issues.apache.org/bloodhound/> The Apache Bloodhound (incubating) issue tracker This is an automated message. Someone added your email address to be notified of changes on 'Proposals/BEP-0003' page. If it was not you, please report to .
