Author: br...@google.com
Date: Fri Apr 24 15:02:18 2009
New Revision: 5282
Modified:
wiki/MultiValuedConfigProperties.wiki
Log:
Edited wiki page through web user interface.
Modified: wiki/MultiValuedConfigProperties.wiki
==============================================================================
--- wiki/MultiValuedConfigProperties.wiki (original)
+++ wiki/MultiValuedConfigProperties.wiki Fri Apr 24 15:02:18 2009
@@ -2,21 +2,18 @@
#labels Phase-Design
== Background ==
-In GWT 1.6, a new module XML element was introduced called
`<set-configuration-property>`.
-Its purpose is to provide to generators and linkers configuration
parameters that cannot be appropriately expressed via deferred binding
properties,
-either because they would never drive multiple permutations or because
they have values that aren't enumerable.
-For example, if a generator needs to be passed a filename at compile-time,
deferred binding properties make no sense, but a configuration property is
perfect.
+In GWT 1.6, a new module XML element was introduced called
`<set-configuration-property>`. Its purpose is to provide to generators and
linkers configuration parameters that cannot be appropriately expressed via
deferred binding properties,
+either because they would never drive multiple permutations or because
they have values that aren't enumerable. For example, if a generator needs
to be passed a filename at compile-time, deferred binding properties make
no sense, but a configuration property is perfect.
-However, in a recent design discussion for RPC blacklist support, we found
`<set-configuration-property>` a bit deficient.
-The subsequent sections explain the current behavior, spotlighting the
problematic aspects.
+However, in a recent design discussion for RPC blacklist support, we found
`<set-configuration-property>` a bit deficient. The subsequent sections
explain the current behavior, spotlighting the problematic aspects.
=== Shared namespace ===
-At present, the namespaces of deferred binding properties and
configuration properties are the same.
-This was intentional, and the original motivations were good:
+At present, the namespaces of deferred binding properties and
configuration properties are the same. This was intentional, and the
original motivations were good:
+
* module writers couldn't accidentally create a configuration property
and deferred binding property with the same name, causing subsequent
ambiguity and
- * it might be useful to transparently change a property from a
configuration property into a deferred binding property.
-Based on the reasoning above, `PropertyOracle#getPropertyValue` is
specified to return either a deferred binding property or a configuration
property.
-Generators can simply query for a property value without knowing whether
they are receiving a configuration property or a deferred binding property
as an answer.
+ * it might be useful to transparently change a property from a
configuration property into a deferred binding property.
+
+Based on the reasoning above, `PropertyOracle#getPropertyValue` is
specified to return either a deferred binding property or a configuration
property. Generators can simply query for a property value without knowing
whether they are receiving a configuration property or a deferred binding
property as an answer.
In retrospect, unifying the namespace creates more problems than it solves.
Although deferred binding properties have a strict identifier-like token
syntax, configuration properties do not,
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
