Я до сих пор have't нашел подробную документацию, но я сделал тонну экспериментов и пришли к следующим выводам ...
(Примечание: мои примеры использования некоторых понятий из Сенча GXT, которые я разрабатываю с)
< define-property > используется для определения свойства и возможных значений, но не является последним словом, в котором значения фактически будут использоваться. В иерархии файлов * .gwt.xml должно быть ровно одно такое определение для свойства.
< установка свойство > не устанавливает свойство в значение, но и создает свой род правило, с набором возможных значений для этого свойства (в идеале до подмножества, что определяется в & ltdefine-свойстве >). Последнее объявление < set-property > для данного свойства выигрывает. Быть осторожен! Если вы используете < set-property > после того, как < наследует > (наследующий модуль), вы можете/будете переопределять любые унаследованные вами правила. Обратите внимание, что существуют условные правила и безусловные правила. Например,
<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 может быть только «сафари», когда «gxt.user.agent» либо «safari5» или «хром».Порядок кажется важным, поэтому вам нужны правила для зависимых свойств, объявленных после правил для их зависимостей. Циклические зависимости не смогут выполнить компиляцию. Вы можете создать множество условных правил, если они не противоречат друг другу. Я еще не знаю, что произойдет, если они это сделают, но я предполагаю, что последний объявленный победит.
Обратите внимание, что условные правила также могут указывать несколько возможных значений. Например (иллюстрация только, может не соответствовать вашим потребностям):
<!-- 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.
Можете ли вы наметить особенности того, что вам нужно? Например, какие «особые условия» и каков будет результат (по сравнению с тем, что он есть)? Предполагая, что в каждом из них есть один-ко-многим OR'd условия, тогда вы должны получать несколько перестановок на 'exact.permutation', так как вы не определили каких-либо коллапсов (по крайней мере, не того, что вы поделили). Без специфики мы не можем видеть то, что вы не понимаете. –
То есть, что вы пробовали, чего вы ожидали, и что вы получили вместо этого?Из этого мы можем либо рассказать вам, что вам не удалось объяснить (и как его исправить, либо поразному по-другому), либо указать обнаруженную вами ошибку (и, возможно, рассказать вам, как ее обойти). –
Моя проблема в том, что я не знаю, что * .gwt.xml constructs делают точно так, как они точно не определены в любом месте. Таким образом, я не могу представить никаких ожиданий - я просто трясусь в темноте. Попытка выяснить, как напрямую управлять перестановками, так и уменьшать их внутреннюю сложность - мне не нужны некоторые случаи, которые поддерживаются вообще, особенно. в некоторых перестановках .. – Learner