conditional linkers and the primary.linker property

41 views
Skip to first unread message

sp...@google.com

unread,
Feb 12, 2010, 4:49:55 PM2/12/10
to robert...@google.com, google-web-tool...@googlegroups.com
Reviewers: robertvawter,

Description:
This patch adds a way that deferred bindings can be differ depending
on the choice of primary linker. This general functionality is
necessary to get runAsync working for the cross-site linker, because
doing so requires compiler rewrites that do not apply to the standard
linker.

After discussing the problem with Bob, a good-looking strategy is to
have the add-linker tag take conditions as an argument. For example,
it could look like this:

<add-linker name="xs">
<when-property-is name="primary.linker" value="xs" />
</add-linker>


This tag adds the xs linker if and only if the primary.linker is set
for all permutations.

To help users understand how this works, if they try to enable a
linker for some but not all permutations, an error message is emitted.
An example error message is as follows:

Linker 'xs' is enabled for some permutations but not all of them


In addition to allawing linkers to be added conditionally, the
recommended way to set a primary linker will change. Currently, users
do this:

<!-- DEPRECATED -->
<add-linker name="xs" />


The new style is like this:

<set-property name="primary.linker" value="xs" />


The old style will still work for any application it already works
for, but will be deprecated. An example deprecation message is as
follows:


[WARN] Linker 'test1' is primary but was not added via primary.linker
Instead of add-linker, use: <set-property name='primary.linker'
value='test1' />
If that doesn't work, contact the linker's maintainer

IMPLEMENTATION

ModuleDef used to have a list of linker classes that build up as the
module is parsed. Now, it has a list of conditional linkers. Once
parsing is complete, ModuleDef.finalizeLinkers should be called, which
makes the final choice of which linkers are enabled.


Please review this at http://gwt-code-reviews.appspot.com/143811

Affected files:
dev/core/src/com/google/gwt/dev/cfg/Condition.java
dev/core/src/com/google/gwt/dev/cfg/ConditionAll.java
dev/core/src/com/google/gwt/dev/cfg/ConditionAny.java
dev/core/src/com/google/gwt/dev/cfg/ConditionNone.java
dev/core/src/com/google/gwt/dev/cfg/ModuleDef.java
dev/core/src/com/google/gwt/dev/cfg/ModuleDefLoader.java
dev/core/src/com/google/gwt/dev/cfg/ModuleDefSchema.java
dev/core/test/com/google/gwt/dev/cfg/ConditionTest.java
dev/core/test/com/google/gwt/dev/cfg/ModuleDefTest.java
user/src/com/google/gwt/core/Core.gwt.xml
user/src/com/google/gwt/core/SsoLinker.gwt.xml
user/src/com/google/gwt/core/StdLinker.gwt.xml
user/src/com/google/gwt/core/XSLinker.gwt.xml
user/test/com/google/gwt/core/ext/IFrameLinkerTest.gwt.xml
user/test/com/google/gwt/core/ext/SingleScriptLinkerTest.gwt.xml
user/test/com/google/gwt/core/ext/XSLinkerTest.gwt.xml
user/test/com/google/gwt/dev/cfg/LinkerTagsTest.gwt.xml
user/test/com/google/gwt/dev/cfg/LinkerTagsTest.java
user/test/com/google/gwt/dev/cfg/LinkerTagsTestBadA.gwt.xml

user/test/com/google/gwt/dev/cfg/LinkerTagsTestUnconditionalPrimary.gwt.xml
user/test/com/google/gwt/dev/cfg/PropertyTest.gwt.xml
user/test/com/google/gwt/dev/cfg/TagSuite.java


Lex Spoon

unread,
Feb 16, 2010, 5:32:08 PM2/16/10
to Bob Vawter, google-web-tool...@googlegroups.com, Scott Blum, Ray Cromwell, Miguel Méndez
On Tue, Feb 16, 2010 at 2:28 PM, Bob Vawter <robert...@google.com> wrote:
>  <set-property name="primary.linker" value="xs" />
>
>
> The old style will still work for any application it already works
> for, but will be deprecated.  An example deprecation message is as
> follows:
>
>
>  [WARN] Linker 'test1' is primary but was not added via primary.linker
>    Instead of add-linker, use: <set-property name='primary.linker'
> value='test1' />
>    If that doesn't work, contact the linker's maintainer

Having had some time to reflect on this design, I really can't get
onboard with this kind of break-fix change.  I'm beginning to think
that an additive approach of making rebinds sensitive to
<when-linker-added> rather than kicking all of our linker-writers in
the shins would be a better way to achieve the specific effect that
you're looking for.

 
Sounds good to me.  I have an implementation of that I could polish up.

Are there any objections to dropping this patch and adding when-linker-added?  It would be used like this:

  <replace-with class="com.google.gwt.core.client.impl.XhrLoadingStrategy">
    <when-type-is
        class="com.google.gwt.core.client.impl.AsyncFragmentLoader.LoadingStrategy"/>
    <when-linker-added name="xs" />
  </replace-with>


Lex


Scott Blum

unread,
Feb 16, 2010, 5:41:12 PM2/16/10
to Lex Spoon, Bob Vawter, google-web-tool...@googlegroups.com, Ray Cromwell, Miguel Méndez
Sounds awesome to me.  I never get comfortable with the other syntax.
Reply all
Reply to author
Forward
0 new messages