gwt 2.7 - Precise control of GWT permutations via *.gwt.xml -

i need precisely specify gwt permutations , control variation within them (combinations of property values supported each) have hard time finding detailed behaviour specification.

during experimentation have learned have watch creating set-property ... when-property-is cycles though these cycles "stable" - i.e. not change part of cycle, "confirm" it. restricted can do, decided try way - define brand new property, (just) example:

  <define-property name="precise.permutation" values="webkit,gecko,ie,unsupported"/> 

... , have like:

  <set-property name="precise.permutation" value="webkit">     <!-- ... custom conditions ... -->   </set-property>   <set-property name="precise.permutation" value="gecko">     <!-- ... custom conditions ... -->   </set-property>   <set-property name="precise.permutation" value="ie">     <!-- ... custom conditions ... -->   </set>   <set-property name="precise.permutation" value="unsupported">     <!-- ... custom conditions ... -->   </set-property> 

... tried restricting unsupported used example entirely counter-intuitive uses same set-property tag above:

  <set-property name="precise.permutation" value="webkit,gecko,ie" /> 

i had collapse other properties make sure don't cause additional permutations.

unfortunately, not seem work intended (tried gwt 2.8 rc2). though "unsupported" permutation not show (this desired), combinations of properties reappear in other permutations (which isn't desired).

can me find authoritative and complete documentation on or me figure out, please?

thanks!

i still have't found detailed documentation have done ton of experimentation , have concluded following...

(note: examples use concepts sencha gxt develop with)

<define-property> used define property , possible values not last word in terms of values used. there should 1 such definition per property in hierarchy of *.gwt.xml files.

<set-property> not set property value creates sort of rule collection of possible values property (ideally subset of defined in &ltdefine-property>). last declaration of <set-property> given property wins. careful! if use <set-property> after <inherits> (inheriting module), may/will overriding rules inherited. note there conditional rules , unconditional rules. example,

<set-property name="gxt.user.agent" value="ie10, ie11, gecko1_9, safari5, chrome"/> 

... unconditionally state that, when determining permutations, property 'gxt.user.agent' can have 1 of listed values. conversely,

<set-property name="user.agent" value="safari">   <any>     <when-property-is name="gxt.user.agent" value="safari5" />     <when-property-is name="gxt.user.agent" value="chrome" />   </any> </set-property> 

will state user.agent can "safari" when "gxt.user.agent" either "safari5" or "chrome". order seems important, want rules dependent properties declared after rules dependencies. cyclic dependencies fail compilation. can create many conditional rules long don't contradict 1 another. not know yet happen if do, guess last declared win.

note conditional rules can specify multiple possible values. example (illustration only, may not match needs):

<!-- on desktops browsers including ie --> <set-property name="gxt.user.agent" value="safari5, chrome, gecko1_9, ie11">   <when-property-is name="gxt.device" value="desktop" /> </set-property> <!-- ... on tablets , phones exclude ie --> <set-property name="gxt.user.agent" value="safari5, chrome, gecko1_9">   <any>     <when-property-is name="gxt.device" value="tablet" />     <when-property-is name="gxt.device" value="phone" />   </any> </set-property> 

you can use <any> , <all> create complex/compound criteria. these can nested inside 1 another.

how can used precise control of permutations? may not need helped me begin defining 2 properties these:

<define-property name="custom.use.case" values="case1, case2, ..."/> <property-provider name="helix.product.mode"><![cdata[        var usecase = ...; // javascript code determine use case     return usecase;   ]]> </property-provider> <define-property name="custom.permutation" values="perm1, perm2, ..."/> 

the first property defines use case. above have way determine @ runtime. may not , may skip it. serves starting point define else can define other properties based on use case. example:

<!-- case 1 restrictions --> <set-property name="gxt.device" value="desktop">   <when-property-is name="custom.use.case" value="case1" /> </set-property> <set-property name="gxt.user.agent" value="chrome, safari5, gecko1_9, ie11">   <when-property-is name="custom.use.case" value="case1" /> </set-property> ...  <!-- case 2 restrictions --> <set-property name="gxt.device" value="tablet, phone">   <when-property-is name="custom.use.case" value="case2" /> </set-property> <set-property name="gxt.user.agent" value="chrome, safari5, gecko1_9">   <when-property-is name="custom.use.case" value="case2" /> </set-property> ...  <!-- case 3 restrictions --> <set-property name="gxt.device" value="tablet, phone">   <when-property-is name="custom.use.case" value="case3" /> </set-property> <set-property name="gxt.user.agent" value="safari5">   <when-property-is name="custom.use.case" value="case3" /> </set-property> ...  etc. 

next thing collapse all properties except custom.permutation, because want custom.permutation drive permutations:

  <collapse-property name="custom.use.case" values="*" />     <collapse-property name="gxt.device" values="*" />   <collapse-property name="gxt.user.agent" values="*" />   <collapse-property name="user.agent" values="*" />   <collapse-property name="user.agent.os" values="*" /> 

this approach allows extremely fine grain control on "permutations" , internal complexity, "soft permutations" call them. there 1 permutation each possible "custom.permutation" property value. each permutation have needed "soft permutations" in if job of setting rules above.

note both actual , soft permutations cost. having many soft permutations (grouped actual permutations or not) costs compile performance , runtime code size of permutation grouped in. not ignore this, if have many properties. actual permutations have higher compile , linking time cost (but having more of them opposed combining many soft permutations grouped actual permutations reduces size of each permutation).

if using gxt, starting version 4, notice adds gxt.device property having values such desktop, tablet , phone. caused our compilation time increase 6-7 times after upgrading gxt 4 because our permutations went out of control. ended being, quite literally, made internet explorer running on mac os tablet. can appreciate waste of time permutations non-existent use cases are. implementing above able reduce gwt compilation time down half of original time or 10-12 times faster right after gxt 4 upgrade.