Page "Proposals/BEP-0003" was changed by olemis Diff URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diff&version=12> Revision 12 Comment: [BEP-0003] Disabled State for Multiproduct Components API (rejected) Changes: -------8<------8<------8<------8<------8<------8<------8<------8<-------- Index: Proposals/BEP-0003 ========================================================================= --- Proposals/BEP-0003 (version: 11) +++ Proposals/BEP-0003 (version: 12) @@ -32,7 +32,7 @@ [[Image(Product_envs_small.png, align=right)]] -In a few words the current proposal tries to reproduce a well-known [./MultienvParentDir multi-environment setup] inside a single enviroment. In this section you'll find the most important details necessary to implement multi-product support. In order to understand the reasons that make this is a valid and reliable specification, please see [#rationale Rationale] below. In order and know more about similar alternatives rejected along the way, please consult [#rejected Rejected ideas] below. +In a few words the current proposal tries to reproduce a well-known [./MultienvParentDir multi-environment setup] inside a single enviroment. In this section you'll find the most important details necessary to implement multi-product support. In order to understand the reasons that make this a valid and reliable specification, please see [#rationale Rationale] below. In order to know more about similar alternatives rejected along the way, please consult [#rejected Rejected ideas] below. === Product environments #product-envs @@ -70,17 +70,6 @@ trac.env.Environment instance as first argument (got multiproduct.env.ProductEnvironment instance instead) -}}} - -Instantiating a component involved in multi-product architecture will always return `None`, just like if it was disabled e.g. - -{{{ -#!py - ->>> from multiproduct.api import MultiProductSystem ->>> ps = product_env[MultiProductSystem] ->>> repr(ps) -None }}} ''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. @@ -259,7 +248,20 @@ Many interesting ideas have been proposed but not all could make their way into final specification because of conceptual, practical or other reasons. Below you'll find the most relevant instances together with brief comments explaining the decision as well as links to relevant messages in [http://mail-archives.apache.org/mod_mbox/incubator-bloodhound-dev/ bloodhound-dev mailing list archive] . - '''TODO''' : nothing rejected so far. +=== Disabled State for Multiproduct Components API (rejected) #rejected-product-api-disabled + +It was suggested that instantiating a component involved in multi-product architecture should always return `None`, just like if it was disabled e.g. + +{{{ +#!py + +>>> from multiproduct.api import MultiProductSystem +>>> ps = product_env[MultiProductSystem] +>>> repr(ps) +None +}}} + +This is not recommended. Multi-product API components will play an active role in customizations at the product level. That will not be possible if they are disabled. == Backwards Compatibility #backwards-compatibility -------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 .
