Жизненный цикл JSF и пользовательские компоненты

Есть несколько вещей, с которыми мне трудно понять время разработки пользовательских компонентов в JSF. Для целей этих вопросов вы можете предположить, что все пользовательские элементы управления используют valuebindings/expressions (не буквальные привязки). Хотя я с радостью поддержу тех, кто дает хорошие объяснения этому, так как это может быть полезно для других (и меня по линии).

Где установить значение для привязки значений? Это должно произойти в декодировании? Или нужно расшифровать сделать что-то еще, а затем установить значение в encodeBegin?
Чтение из привязки значений. Когда я читаю данные из привязки value или считывая ее из представленного значения и помещая его в значение привязки?
Когда вы слушаете действия в формах, связанных со всем этим? На страницах жизненного цикла JSF упоминаются события, происходящие на разных этапах, но это не совсем понятно для меня, когда вызывается просто простой прослушиватель для командной строки

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

Ответ 1

Ответ 2

Слушатели действий, например, для CommandButton, вызываются во время фазы Invoke Application, которая является последней фазой перед заключительной фазой Render Response. Это показано в Жизненный цикл JSF - рисунок 1.

Ответ 3

Это единственная структура, в которой я когда-либо используется, когда создание компонента такой сложный процесс. Ни одна из других веб-фреймворков (будь то в мире .net или нет) сделайте это настолько болезненным, что совершенно необъяснимым для меня.

Некоторые дизайнерские решения, стоящие за JSF, начинают иметь смысл, когда вы рассматриваете цели. JSF был разработан для оснастки - он предоставляет множество метаданных для IDE. JSF не является веб-картой - это MVP, которая может использоваться как веб-инфраструктура. JSF очень расширяема и настраивается - вы можете заменить 90% реализации на основе каждого приложения.

Большая часть этого материала просто усложняет вашу работу, если все, что вы хотите сделать, - это ускользнуть от дополнительного элемента управления HTML.

Компонент представляет собой состав несколько исходных текстов (и других) баз компоненты, кстати.

Я предполагаю, что фрагменты страницы JSP-includes/tooling не соответствуют вашим требованиям.

Я хотел бы использовать ваш UIComponentELTag.createComponent для создания составного элемента управления с базой UIPanel и создания всех его дочерних элементов из существующих реализаций. (Я предполагаю, что вы используете JSPs/taglibs и делаете несколько других догадок.) Вероятно, вы захотите создать собственный рендерер, если ни один из существующих визуализаторов UIPanel не выполнит эту работу, но рендеринги просты.

Ответ 4

@McDowell - Спасибо за информацию... Я смог узнать большую часть этого утром, прочитав код MyFaces, но вы добавили и уточнили ряд подробных сведений, которые могут быть полезны.

Я бы поставил под вопрос, почему вы пишете свой собственный UIComponent. Это нетривиальная задача, и для ее правильного понимания необходимо глубокое понимание архитектуры JSF.

Честно говоря, я боролся с тем, использовать ли вообще JSF именно по этой причине. Это единственная структура, которую я когда-либо использовал, когда создание компонентов - это глубокий сложный процесс, подобный этому. Ни одна из других веб-фреймворков (будь то в мире .net или нет) делает это настолько болезненным, что совершенно необъяснимо для меня.

Я застрял с JSF в основном за обещание, что 2.0 сделает его намного менее болезненным. Компонент представляет собой композицию из нескольких базовых компонентов входного текста (и других), btw.

Ответ 5

@McDowell:

Некоторые дизайнерские решения, стоящие за JSF, начинают иметь смысл, когда вы рассматриваете цели. JSF был разработан для оснастки - он предоставляет множество метаданных для IDE. JSF не является веб-картой - это MVP-инфраструктура, которая может использоваться как веб-инфраструктура. JSF очень расширяема и настраивается - вы можете заменить 90% реализации на основе каждого приложения.

Из этого, я думаю, единственная часть, с которой я согласен, это "немного больше смысла". В JSF 1.2 метаданные могли быть показаны другими способами, и, честно говоря, мне еще предстоит увидеть, как IDE делает его достойным использованием. Почему среда IDE не дает мне простой способ создания компонента?

Я также использовал ASP.Net, и для сравнения JSF чувствует, что это было написано группой астронавтов архитектуры во главе с таким парнем, как оригинальный дизайнер Struts. О, подождите...:)

Ответ 6

Лучшая статья, которую я нашел, - Jsf Component Writing, как для 2, где я читаю значение привязки значения в вашем компоненте, у вас есть getter, который выглядит следующим образом


public String getBar() {  
     if (null != this.bar) {  
         return this.bar ;  
     }  
     ValueBinding _vb = getValueBinding("bar");  
     return (_vb != null) ? (bar) _vb.getValue(getFacesContext()) : null;  
}

как это попало в getValueBinding? В вашем методе класса setProperties метод

  if (bar!= null) {  
         if (isValueReference(bar)) {  
             ValueBinding vb = Util.getValueBinding(bar);  
             foo.setValueBinding("bar", vb);  
         } else {  
             throw new IllegalStateException("The value for 'bar' must be a ValueBinding.");  
         }  
     }