Я до сих пор не нашел подробной документации, но я провел массу экспериментов и пришел к следующему выводу...
(Примечание: в моих примерах используются некоторые концепции Sencha GXT, с которыми я разрабатываю)
‹define-property› используется для определения свойства и его возможных значений, но не является последним словом в отношении того, какие значения будут фактически использоваться. Для каждого свойства в иерархии файлов *.gwt.xml должно быть ровно одно такое определение.
‹set-property› НЕ присваивает свойству значение A, а создает своего рода правило с НАБОРОМ ВОЗМОЖНЫХ значений для этого свойства (в идеале — подмножество того, что определено в <define-property›). Последнее объявление ‹set-property› для данного свойства выигрывает. Будь осторожен! Если вы используете ‹set-property› после ‹inherits› (наследование модуля), вы можете/будете переопределять любые унаследованные правила. Обратите внимание, что существуют условные правила и безусловные правила. Например,
<set-property name="gxt.user.agent" value="ie10, ie11, gecko1_9, safari5, chrome"/>
... будет безоговорочно утверждать, что при определении перестановок свойство 'gxt.user.agent' может иметь любое из перечисленных значений. Наоборот,
<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>
Будет указано, что user.agent может быть «safari» только тогда, когда «gxt.user.agent» является либо «safari5», либо «chrome». Порядок кажется важным, поэтому вам нужно, чтобы правила для зависимых свойств объявлялись после правил для их зависимостей. Циклические зависимости не смогут выполнить компиляцию. Вы можете создать множество условных правил, если они не противоречат друг другу. Я пока не знаю, что будет, если они это сделают, но предполагаю, что победит последний объявленный.
Обратите внимание, что условные правила также могут указывать несколько возможных значений. Например (только иллюстрация, может не соответствовать вашим потребностям):
<!-- On desktops we do all 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>
<!-- ... but on tablets and phones we 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>
Вы можете использовать «любой» и «все» для создания сложных/составных критериев. Они могут быть вложены друг в друга.
Как это можно использовать для точного управления перестановками? Возможно, вам это не понадобится, но мне помогло начать с определения двух таких свойств:
<define-property name="custom.use.case" values="case1, case2, ..."/>
<property-provider name="helix.product.mode"><![CDATA[
var useCase = ...; // JavaScript code to determine the use case
return useCase;
]]>
</property-provider>
<define-property name="custom.permutation" values="perm1, perm2, ..."/>
Первое свойство определяет вариант использования. Выше у меня есть способ определить это во время выполнения. Вы не можете и можете пропустить это. Он также служит отправной точкой для определения всего остального, поскольку мы можем определить все остальные свойства на основе варианта использования. Например:
<!-- 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.
Следующее, что нужно сделать, это свернуть все свойства, кроме для custom.permutation, потому что мы хотим, чтобы custom.permutation управлял перестановками:
<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="*" />
Этот подход позволяет чрезвычайно точно контролировать «перестановки» и их внутреннюю сложность, «мягкие перестановки», как некоторые их называют. Для каждого возможного значения свойства custom.permutation будет ровно одна перестановка. Каждая перестановка будет иметь только необходимые «мягкие перестановки», если вы хорошо справитесь с настройкой приведенных выше правил.
Обратите внимание, что как фактические, так и мягкие перестановки стоят. Наличие большого количества мягких перестановок (сгруппированных в фактические перестановки или нет) снижает производительность компиляции и размер кода среды выполнения перестановки, в которую они сгруппированы. Не игнорируйте это, особенно если у вас много свойств. Фактические перестановки имеют еще более высокие затраты времени на компиляцию и связывание (но их большее количество, в отличие от объединения многих мягких перестановок в сгруппированные фактические перестановки, уменьшает размер каждой перестановки).
Если вы используете GXT, начиная с версии 4, вы заметите, что он добавляет свойство gxt.device, имеющее такие значения, как рабочий стол, планшет и телефон. Это привело к увеличению времени компиляции примерно в 6-7 раз после обновления до GXT 4, потому что наши перестановки вышли из-под контроля. Некоторые из них в буквальном смысле были созданы для Internet Explorer, работающего на планшете с Mac OS. Вы можете оценить, какой пустой тратой времени являются перестановки для несуществующих вариантов использования. Реализовав вышеизложенное, мы смогли сократить время компиляции GWT примерно до половины исходного времени или примерно в 10-12 раз быстрее, чем сразу после обновления GXT 4.
person
Learner
schedule
13.09.2016
precise.permutation
, поскольку вы не определили никакого свертывания (по крайней мере, вы не разделили ). Без конкретики мы не можем увидеть то, чего вы не понимаете. - person Colin Alworth   schedule 13.09.2016<set-property>
, вы можете уменьшить значения, которые возможны глобально, а условные теги позволяют гарантировать определенное значение для этого свойства только в этом конкретном случае. Правила свертывания аналогичны безусловным правилам, поскольку они сокращают возможное количество значений. Это действительно так - правила могут показаться простыми (или могут быть кратко написаны), но правил больше нет, просто нужно буквально следовать этим правилам. Больше не нужен пример. - person Colin Alworth   schedule 13.09.2016