Большинство неполадок проверки 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}/> | Если атрибут тега требует записываемое свойство, а получает только для чтения, агент проверки обнаружит эту неполадку. |