JSF getValue () v.s. getSubmittedValue ()
В Java все переменные, которые вы объявляете, на самом деле являются «ссылками» на объекты (или примитивы), а не самими объектами.
При попытке выполнить один метод объекта , ссылка просит живой объект выполнить этот метод. Но если ссылка ссылается на NULL (ничего, нуль, void, nada), то нет способа, которым метод будет выполнен. Тогда runtime сообщит вам об этом, выбросив исключение NullPointerException.
Ваша ссылка «указывает» на нуль, таким образом, «Null -> Pointer».
Объект живет в памяти виртуальной машины пространство и единственный способ доступа к нему - использовать ссылки this. Возьмем этот пример:
public class Some {
private int id;
public int getId(){
return this.id;
}
public setId( int newId ) {
this.id = newId;
}
}
И в другом месте вашего кода:
Some reference = new Some(); // Point to a new object of type Some()
Some otherReference = null; // Initiallly this points to NULL
reference.setId( 1 ); // Execute setId method, now private var id is 1
System.out.println( reference.getId() ); // Prints 1 to the console
otherReference = reference // Now they both point to the only object.
reference = null; // "reference" now point to null.
// But "otherReference" still point to the "real" object so this print 1 too...
System.out.println( otherReference.getId() );
// Guess what will happen
System.out.println( reference.getId() ); // :S Throws NullPointerException because "reference" is pointing to NULL remember...
Это важно знать - когда больше нет ссылок на объект (в пример выше, когда reference и otherReference оба указывают на null), тогда объект «недоступен». Мы не можем работать с ним, поэтому этот объект готов к сбору мусора, и в какой-то момент VM освободит память, используемую этим объектом, и выделит другую.
2 ответа
Поскольку это результат №1 в Google для поиска по getValue и getSubmittedValue, я просто хотел бы добавить, что разница между ними имеет решающее значение при проверке (т.е. при написании собственного валидатора)
Процитируем документацию API для getSubmittedValue ():
Это ненулевое значение только между декодированием и проверить фазы, или когда проверка для компонента не удалось. После преобразования и проверка прошла успешно, (преобразованное) значение сохраняется в локальное свойство "значения" этого компонент, а представленное значение сбросить до нуля.
Источник: http://myfaces.apache.org/core11/myfaces-api/apidocs/javax/faces/component/UIInput.html#getSubmittedValue ()
Это означает, что если проверка / преобразование выполнялись для привязки, к которой вы пытаетесь получить доступ, вы должны вызвать getValue (), иначе вам придется вызвать getSubmittedValue () и разобраться с его анализом самостоятельно. Порядок, в котором они происходят, кажется, продиктован порядком, в котором они появляются в пользовательском интерфейсе, но я не думаю, что это гарантировано. Даже если это так, вы не должны рассчитывать на это, поскольку изменение поля в вашем пользовательском интерфейсе не должно нарушать ваш код.
Вы можете определить, была ли выполнена проверка / преобразование, просто посмотрев, что возвращает isLocalValueSet (). Если он возвращает true, значит проверка / преобразование было выполнено, поэтому вам следует вызвать getValue (). В противном случае вы Мне нужно вызвать getSubmittedValue (), и это даст вам необработанный ввод, введенный пользователем, и вы, вероятно, захотите проанализировать его во что-то более значимое.
Например, объект календаря вернет объект Date, когда getValue ( ), но при вызове getSubmittedValue () был вызван объект String. Ваш конвертер должен преобразовать строку в дату, чтобы ее можно было проверить.
Было бы здорово, если бы в спецификации JSF был метод, который сделал бы это за нас, но, AFAIK, этого нет. Если определенные даты должны быть раньше других дат, а некоторые требуются только при определенных обстоятельствах, для этого потребуется написать несколько валидаторов. Так что это легко может стать проблемой. Это похоже на тот факт, что вы не можете выполнять какие-либо проверки для пустого поля, что означает, что вы не можете сделать это поле условно обязательным. Если проверка выполнялась для всех полей, даже для пустых, можно написать настраиваемый валидатор, который генерирует исключение, если это необходимо, а не требуется. Есть некоторые вещи с JSF, которые просто неудобны; до тех пор, пока они не будут исправлены, нам просто нужно с ними разобраться.
Говоря о деталях проблемы в исходном сообщении: разница здесь в том, где вы находитесь в жизненном цикле. Метод submit выглядит как прослушиватель действия для кнопки, который помещает ее в конец жизненного цикла; Действия и прослушиватели действий запускаются на этапе «Вызов приложения», который предшествует ответу на рендеринг, но после проверки. Если вы собираетесь программировать на JSF, вам следует изучить и понять жизненный цикл. Это того стоит.
Говоря о деталях проблемы в исходном сообщении: разница здесь в том, где вы находитесь в жизненном цикле. Метод submit выглядит как прослушиватель действия для кнопки, который помещает ее в конец жизненного цикла; Действия и прослушиватели действий запускаются на этапе «Вызов приложения», который предшествует ответу на рендеринг, но после проверки. Если вы собираетесь программировать на JSF, вам следует изучить и понять жизненный цикл. Это того стоит.
Говоря о деталях проблемы в исходном сообщении: разница здесь в том, где вы находитесь в жизненном цикле. Метод submit выглядит как прослушиватель действия для кнопки, который помещает ее в конец жизненного цикла; Действия и прослушиватели действий запускаются на этапе «Вызов приложения», который предшествует ответу на рендеринг, но после проверки. Если вы собираетесь программировать на JSF, вам следует изучить и понять жизненный цикл. Это того стоит.
Говоря о деталях проблемы в исходном сообщении: разница здесь в том, где вы находитесь в жизненном цикле. Метод submit выглядит как прослушиватель действия для кнопки, который помещает ее в конец жизненного цикла; Действия и прослушиватели действий запускаются на этапе «Вызов приложения», который предшествует ответу на рендеринг, но после проверки. Если вы собираетесь программировать на JSF, вы должны изучить и понять жизненный цикл. Это того стоит.
Говоря о деталях проблемы в исходном сообщении: разница здесь в том, где вы находитесь в жизненном цикле. Метод submit выглядит как прослушиватель действия для кнопки, который помещает ее в конец жизненного цикла; Действия и прослушиватели действий запускаются на этапе «Вызов приложения», который предшествует ответу на рендеринг, но после проверки. Если вы собираетесь программировать на JSF, вам следует изучить и понять жизненный цикл. Это того стоит.
submit выглядит как прослушиватель действия для кнопки, который помещает ее в конец жизненного цикла; Действия и прослушиватели действий запускаются на этапе «Вызов приложения», который предшествует ответу на рендеринг, но после проверки. Если вы собираетесь программировать на JSF, вы должны изучить и понять жизненный цикл. Это того стоит. Метод submit выглядит как прослушиватель действия для кнопки, который помещает ее в конец жизненного цикла; Действия и прослушиватели действий запускаются на этапе «Вызов приложения», который наступает перед ответом на рендеринг, но после проверки. Если вы собираетесь программировать на JSF, вам следует изучить и понять жизненный цикл. Это того стоит. Заключить документацию в кавычки относительно EditableValueHolder.getSubmittedValue:
Возвращают submittedValue значение этого компонента. Этот метод должен только использоваться encodeBegin () и/или encodeEnd () методы этого компонента или его соответствующий Рендерер.
Обычно Вы даже не звонили бы getValue. Вместо этого компонент значение атрибут должен быть связан с Вашей моделью (боб, возможно). Ваша бизнес-логика взаимодействовала бы с моделью, не компонентом.
, Если бы отправленное значение не устанавливается как значение, то я предположил бы, что некоторая проверка перестала работать. Единственная проблема с этим состоит в том, что Ваше событие запускается. Два предположения для проблемы здесь:
- у Вас есть устаревшая ссылка на объект компонента.
- Вы установили непосредственный атрибут на UICommand, что означает, что событие запущено в фазу, где компонент будет в несоответствующем состоянии.
не возможно быть бесспорным с предоставленной информацией.