incubator-bloodhound-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Apache Bloodhound" <bloodhound-...@incubator.apache.org>
Subject [Apache Bloodhound] Proposals/BEP-0003 modified
Date Mon, 14 Jan 2013 07:17:57 GMT
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 .

Mime
View raw message