Изменение параметров проверки EL


Большинство неполадок проверки EL может иметь настройки их серьезности как ошибка, предупреждение и нет. Серьезность нет фактически игнорирует ошибку для целей отчетности.

Параметры серьезности неполадок EL

Для того чтобы изменить серьезность конкретного типа неполадок EL, откройте окно параметров следующим образом:
Окно -> Параметры... -> Web ->JavaServer Faces Tools -> Проверка:


Параметры агента проверки EL

Описания неполадок


В следующей таблице приводится каждая неполадка, которая может иметь настройку серьезности, и описывается ее действие:

ОписаниеПримерОписание
Общая синтаксическая ошибка#{* x}Синтаксические ошибки являются общими нарушениями языка EL. В данном примере оператор умножения '*' предполагает два операнда, а имеется только один (x).
Пустое выражение EL#{}Показывает, что выражение отсутствует.
В выражении пропущена закрывающая скобка#{x + 5Показывает, что необходимо добавить закрывающую скобку '}' в "#{x + 5}"
Применение оператора к методу обязательно#{bean.action * 5}Если bean.action указывает метод "action()" на объекте, то обработка своего результата как значения EL недопустима. В приведенном примере действие умножения на 5 обрабатывает его как значение.
Имена свойств с точками должны использовать синтаксис массива ([]).#{property.name.foo}Если name.foo является ключом значения в индексе комплекта свойств на property, то спецификация EL рекомендует (хотя и не требует), чтобы вместо него использовалось выражение property['name.foo'], чтобы подчеркнуть тот факт, что name.foo является ключом в отображении, а не, скажем, свойством объекта.
Переменная не найдена#{bean property}Если bean не может быть разрешен как переменная, то эта неполадка обнаруживается. Поскольку на этапе разработки все 100% переменных, которые могут быть активны во время выполнения, не известны, то на время может быть полезно подавить эту неполадку для сокращения ложных обнаружений.
Элемент не найден#{bean property}Если property не может быть разрешено как свойство bean, то эта неполадка обнаруживается. Например, если bean является классом без методов getProperty/setProperty. Несмотря на то, что очень маловероятно, что эта проверка будет приводить к ложным обнаружениям, если используется много разных возможных источников переменных типа тегов, то ее, вероятно, лучше игнорировать.
Свойство является промежуточным#{property.name}Эта неполадка возникает, поскольку EL допускает символ '.' в именах ключей (как в bean['x.y']), а также позволяет использовать его как оператор элемента (как в bean.property). Это может запустить пользователя, особенно в случаях, подобных примеру, в котором property представляет отображение на фоне комплекта ресурсов (то есть файла свойств). Для этого примера предположим, что для name.foo имеется ключ. Тогда оператор property.name может выглядеть значимым, хотя он и не имеет ключа в комплекте, и будет приводить либо к пустому значению, либо к исключительной ситуации во время выполнения.
Неполадки приведения к числу в двоичной операции#{5 * true}Некоторые двоичные операторы (например '+', '-', '*', '/' и модуль, которые имеют два операнда, как в x + y) предполагают, что оба операнда могут быть приведены к числам перед применением операции. В этом примере true является буквенным литералом, который не имеет действительного приведения к численному значению (хотя некоторые реализации принуждают приведение к виду типа С). Такие ошибки приведения обычно вызывают исключительные ситуации во время выполнения. Отметим, что переменные (то есть bean.booleanProperty) также имеют некоторые проблемы с приведением; они не ограничиваются литералами.
Неполадки приведения к булеву значению в двоичной операции#{myBean.integerProperty && true}Некоторые двоичные операнды (например &&, ||) предполагают, что оба операнда могут быть приведены к булевым значениям перед применением операции. В этом примере myBean.integerProperty является свойством объекта типа "целое число". EL не допускает приведения численных типов в булевы (хотя некоторые реализации могут принуждать приведение к типу С).
Двоичная операция не имеет приведения#{myBean.stringArrayProperty >= myBean.booleanProperty}Эта неполадка обнаруживается, когда двоичному оператору, например >= назначаются операнды, ни один из которых не может быть приведен значимым образом для получения типа операндов. В данном примере ни stringArrayProperty, ни booleanProperty не является достоверным значением, которое можно бы было сравнить с помощью оператора ">=".
Двоичное приведение литерала к числу#{'a' + 'b'}EL иногда допускает приведение строчных значений к числам. Например, #{'5' + '6'} допустимо, поскольку как '5', так и '6' может быть преобразовано в числа с помощью Long.valueOf(). Однако аналогичные приведения недопустимы, если такие преобразования не могут быть сделаны. На стадии проектирования мы можем узнать о таких недействительных преобразованиях, только если воздействуемое значение является литералом (если оно является переменной, то обычно мы ничего не будем знать до момента выполнения). В данном примере мы можем с уверенностью сказать, что ни 'a', ни 'b' не могут быть преобразованы к численному типу, ожидаемому оператором +.
Неполадка приведения к числу в унарной операции#{-myBean.mapProperty}Унарный оператор минус предполагает, что его операнд может быть приведен к численному типу перед применением операции. В данном примере myBean.mapProperty является типом java.util.Map, который не имеет достоверного приведения к числу.
Неполадка приведения к булеву значению в унарной операции#{!myBean.mapProperty}Унарный оператор not предполагает, что его операнд может быть приведен к булеву типу перед применением операции. В данном примере myBean.mapProperty является типом java.util.Map, который не имеет достоверного приведения к булеву значению.
Приведение строки в унарном операторе не гарантируется#{-myBean.stringProperty} Приведение строки к числу, как предполагает унарный оператор минус, не гарантируется в зависимости от значения строки. Такие возможные неполадки обнаруживаются.
Оба операнда нулевые#{null + null} Когда оба операнда нулевые, результатом является константа, которая может быть свернута вручную (заменена литеральной константой) для сокращения кода.
Двоичное выражение всегда дает одно и то же значение#{x + 5 * 4} Когда оба аргумента двоичного выражения являются литералами, операция может быть свернута на стадии разработки. Например, это выражение можно упростить до #{x+20}.
Сравнение равенства с нулем всегда дает одно и то же значение#{myBean.integerProperty == null} Равенства и относительные сравнения EL ('==', '!=', '>=' и т.д.) с нулем всегда дают одно и то же значение. Вообще говоря, неравенство дает в результате значение true, а равенство и операторы сравнения - значение false.
Нумерационное сравнение всегда дает одно и то же значение#{myBean.coins == 'notAValue'} Поскольку возможные значения нумерации (Java 5 и следующие) известны во время компиляции, мы можем ввести правила сравнения, которые всегда будут давать одно и то же значение. В данном примере notAValue не является членом нумерации Coins, поэтому известно, что равенство никогда не будет true.
Унарное выражение всегда дает одно и то же значение#{empty 'notEmpty'} Унарные операторы имеют операнды, для которых во время разработки можно определить так, чтобы они всегда давали одно и то же значение. В данном примере оператор empty всегда дает в результате значение при применении к ненулевой, непустой строке.
Пустой оператор всегда дает значение false на типе#{empty myBean.integerProperty} Оператор empty всегда дает значение false, если его операндом не является нулевое значение, пустая строка или массив типа Map или Collection.
Минус в применении к нулю всегда дает нуль#{-null} Нуль фактически приводится к нулю, когда к нему применяется оператор минус.
Первый аргумент замыкает выражение#{false && someFunc()} "Замыкание" условных операторов EL означает, что если первый операнд обеспечивает достаточную информацию, чтобы быть уверенным в результате, второй операнд не оценивается. В данном примере someFunc() не вызывается никогда, поскольку логическое AND значения 'false' с любым значением всегда false. Поскольку это обнаруживается во время разработки, эта неполадка указывает на бесполезное или свертываемое вручную выражение.
Второй аргумент всегда дает одно и то же#{myBean.booleanProperty && false} Эта неполадка аналогична предыдущей, только выражение не замыкается. В данном примере выражение всегда будет false.
Применение оператора точки ('.') к нулю всегда возвращает нуль#{map[null]} Применение нуля в качестве аксессора элемента всегда дает в результате нуль.
Возможное деление на ноль#{x mod 0} Деление и значение по модулю 0 может привести к исключительной ситуации во время выполнения.
Индекс может быть вне границ#{myBean.stringArrayProperty[-1]} Индексы массива должны быть больше или равны 0 и меньше размера массива или набора (как в Java). Эта неполадка обнаруживается, когда во время разработки определяется возможность нарушения этих ограничений.
Несовместимое нумерационное сравнение#{myBean.coins >= myBean.colors} Сравнение двух нумерационных значений, которые не принадлежат к одному типу нумерации (Java 5 и следующие), может привести к исключительной ситуации во время выполнения.
Ожидается выражение метода<h:commandButton action="#{bean.property}"/> Если агент проверки EL имеет информацию, что атрибут тега ожидает выражение метода (привязку метода перед JSF 1.2), он обозначит ошибку, если выражение EL оценивает выражение значения. В данном примере bean.property является выражением значения, дающим свойство ядра на bean.
Несовместимость типов выражений значений<h:inputText rendered="#{bean.foo}/> Если агент проверки EL имеет информацию, что атрибут тега ожидает значение определенного типа, то он обозначит ошибку, если выражение не может быть приведено к этому типу. В данном примере bean.foo является свойством объекта типа Foo объектов. Произвольный тип класса обычно не может быть приведен к булевым значениям (результат должен быть булевым).
Ожидалось выражение значения<h:inputText value="#{bean.action}/> Если атрибут тега ожидает значение, то неполадка будет обнаружена, если вместо него определяется выражение метода. В данном примере атрибут значения предполагает выражение значения, а вместо него предоставляется выражение метода (другого способа определить, что это выражение метода, кроме как посмотреть на него). Необходимо оценить, что action на bean справедливо.
Несовместимость сигнатур выражений методов<h:commandButton action="#{bean.actionTakesArg}" Если ожидаемая сигнатура выражения метода известна, то агент проверки сравнит ее с данным выражением и обнаружит неполадку, если нет совпадения. В данном случае атрибут action ожидает метод без аргументов, но получает метод с аргументами.
Свойство предполагается читаемым, но без метода get<h:outputText value="#{bean.writeOnlyProperty}/> Если атрибут тега требует читаемое свойство, а получает нечитаемое, агент проверки обнаружит эту неполадку.
Свойство предполагается записываемым, но без метода set<h:inputText value="#{bean.readOnlyProperty}/>Если атрибут тега требует записываемое свойство, а получает только для чтения, агент проверки обнаружит эту неполадку.

Связанные задачи

Проверка приложений JSF