JavaServer Faces Технологията JavaServer Faces

Пример за JSF приложение

• 
  Мапване на FacesServlet в web.xml.
  
• 
  Създаване на страниците използвайки основните JSF тагове и тези за HTML компонентите.
  
• 
  Свързваме данните от първата страница с backing bean.
  
• 
  Дефинираме навигацията между страниците във faces-config.xml.
  
• 
  Построяваме backing beans и ги декларираме нашите backing beans в faces-config.xml.
  

Всяко JSF приложение трябва да дефинира FacesServlet в web.xml. Този сървлет обработва заявките и стартира жизнения цикъл на приложението. С две думи, този жизнен цикъл се грижи за събитията, валидацията, генерирането на крайния HTML, който получава браузъра и всички останали JSF специфични процедури. web.xml трябва да съдържа следното:

Създаваме страницата inputname.jsp. Тази страница съдържа поле за въвеждане на име и бутон за събмитване на данните.

За да можем да ползваме UI компонентите на JSF, включваме двете таг-библиотеки в началото и:

<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %> <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>

Включваме локализираните низове, които ще използваме:

Това е файлът text.properties във формат име=стойност, който се намира в пакета com.dreamix.jsf.bundle.

В едно JSF приложение, всяка страница е представена като дърво от компоненти. Добавяме тагът за да обозначим коренът на това дърво. Т.е всички останали компоненти трябва да се намират вътре в този таг.

Поставяме описателен текст:

Добавяме формата:

Добавяме компонентите във формата - подсещащ текст, текстово поле за въвеждане на името и бутон за изпращане на формата:

Приложението се състои от две части – в първата въвеждаме име, във втората показваме това име. Трябва ни начин да запазим стойността, която сме въвели в първата страница и да покажем тази стойност във втората. Това се постига с т.н. backing beans или managed beans. Те представляват JavaBean класове и техните пропъртита могат да се използват директно в JSP страницата, чрез UEL.

Добавяме атрибута value на inputText компонентата във формата на inputname.jsp, като свързваме стойността и с пропъртито name на backing bean PersonBean:

В greetings.jsp свързваме пропъртито name на PersonBean (това пропърти е вече попълнено от предишната страница със стойността на инпут полето) с UI компонентата, която ще визуализира въведеното име:

Дефинираме навигацията между страниците

За създаването на навигация между страниците, т.е коя страница да се появи след натискането на бутон или хипер линк, е използва система от правила описана в конфигурационния файл на JSF приложението. Тези правила представляват съпоставяне на страница, различни действия, които произлизат от тази страница и съответните страници, които ще се покажат при всяко едно от действията.

Указваме името на действието, което ще се инициира при натискане на събмит бутона Hello по следния начин:

action="greeting" value="#{txt.button_text}" />

Дефинираме правилото във faces-config.xml:

/inputname.jsp greeting /greetings.jsp

Посочваме, че при натискане на бутона, ще се появи страницата greetings.jsp.

Правилата са в следния формат:

Създаваме класа PersonBean в пакета com.dreamix.jsf по следния начин:

определя името на bean, чрез което ще бъде достъпван от JSP страницата

определя fully qualified name на класа на bean

определя обхвата на bean. В случая трябва да предадем данни от едната страница в другата, затова PersonBean може да живее само между двете страници т.е. в една заявка.

Демонстрация

Среди за разработка

Архитектурата на JSF позволява голяма част от нещата да бъдат автоматизирани. Все повече среди за разработка предлагат поддръжка на JSF:

• 
  NetBeans предлага вградена частична поддръжка за JSF. Помага създаването на навигационни правила. Предлага автоматични подсказки за JSF таговете при създаване на JSP страницата. Улеснява създаването на Managed (Backing) Beans и предлага автоматични подсказки за техните пропъртита.
  

NetBeans предлага плъгинът Visual Web Pack. Този плъгин предлага WYSIWYG редактор за JSF страници, редица диалози за свързване към backing beans, методи, валидатори и т.н. За съжаление има проблеми и това го прави почти неизползваем.

• 
  Eclipse Тъй като JSF приложението е Java Уеб приложение, Eclipse предлага плъгинът WTP за редактиране на JSP страници и автоматично деплойване. Недостатък е, че на ръка трябва да се създават всички JSF специфични неща. В WEB-INF/lib директорията трябва да присъстват следните jar файлове: commons-beanutils.jar, commons-collections.jar, commons-digester.jar, commons-logging.jar, jstl.jar, standard.jar и jsf-api.jar, jsf-impl.jar (или съответните jar файлове за съответната имплементация на JSF стандартът). Предвидено е следващи версии на плъгинът да предлагат по пълна поддръжка на JSF.
  

Eclipse предлага плъгинът MyEclipse. Предоставя автоматизация на всичко необходимо за едно JSF приложение. Платено е (предоставя 30 дневна пробна версия) и е пълно с бъгове - неизползваемо.

• 
  JDeveloper предлага вградена пълна поддръжка на JSF. WYSIWYG редакторът наистина генерира очакваното. За съжаление JDeveloper не е от най-удобните среди за разработка на Java код.
  
• 
  IntelliJ IDEA е един от най-добрите среди за разработка на Java. Платена е. Предоставя минимална поддръжка за JSF като визуално създаване на навигационни правила.
  

Демонстрация с JDeveloper

Добавяне на валидация и съобщения за грешки

Нека направим полето за въвеждане на името задължително. Най-лесния начин да направим това е чрез добавяне на атрибута required със стойност true:

По този начин приложението няма да продължи според създадените навигационни правила и ще покаже формата отново.

За да направим приложението по-интерактивно добавяме лейбъл, в който ще бъдат изписани всички грешки при валидация за съответното инпут поле:

С тагът се указва къде да се показват всички съобщения за грешки.

Съществуват още няколко вградени валидатора: validateLength, validateDoubleRange, validateLongRange съответно за валидиране на дължина на текстово поле, за валидиране на минимални и максимални стойности от съответния тип. Ето как се използва валидатора за дължина на текст в текстово поле:

JSF предлага лесен начин за построявване на собствени валидатори. Това ще го разлгедаме по-нататък.

Използване на стандартните конвертери за данни

В HTML страницата всичко е текст. JSF предоставя няколко начина за конвертиране на данни:

• 
  Чрез свързване към съответния тип данни в backing bean
  
• 
  Чрез посочване на стандартен или собствен конвертер
  

Съществуват два стандартни конвертера – convertDateTime и convertNumber съответно за преобразуване на дата и число (примерно валута или число в определен формат).

Пример за използване на конвертера за дата:

Този таг изписва на страницата дата със следния формат : Понеделник, XII 11, 2006.

JSF отвътре

JSF компонентен модел

JSF предлага компонентна архитектура, която включва следните неща:

• 
  Набор от класове за манипулиране и определяне на състоянието на HTML компонентите
  
• 
  Модел за рендериране на компонентите
  
• 
  Събитиен модел за прихващане на събития за специфични компоненти
  
• 
  Конвертен модел за преобразуване на типове данни от HTML компонентата към Java кода и обратно
  
• 
  Валидационнен модел за валидиране на съответните компоненти
  

Набор UIComponent от класове

Всяка HTML компонента има съответния клас, наследяващ UIComponentBase.

Пример:

UICommand – h:commandButton и h:commandLink

UIOutput – h:outputText и h:outputLabel

Съответно всяка HTML компонента може да бъде свързана с обект от съответния и тип посредством атрибута binding. Пример:

Input e пропърти на PersonBean и е от тип UIInput със съответните методи за достъп (get и set). Пропъртито PersonBean.input представя текущото състояние на h:inputText компонентата и позволява това състояние да бъде променено. Пример за това ще дам по-късно.

Модел за рендериране на компонентите

Освен с клас от тип UIComponentBase, всяка компонента си има свой рендерър, който е изнесен в отделен клас и определя как компонентата ще е представена на клиента (Пример: Ако клиента е Уеб браузър, рендерерът определя HTML кода, който ще визуализира съответната компонента).

Render kit определя как класовете на компонентите се свързват със съответните тагове за да се получи подходящ изход за съответния клиент. JSF предоставя стандартен render kit, който включва HTML рендерери за HTML клиенти.

Render kit включва набор от Renderer класове за всяка компонента. Всеки такъв рендерер определя специфичния HTML за компонентата. Пример: UICommand има два реднерера – за събмит бутон и за хиперлинк събмитваш форма.

Конвертен модел

За JSF приложението данните са в два варианта – моделен (реалния тип на данните int, long ...) и визуален изглед на данните (данните са представени на потребителя и той може да ги променя). Конвертния модел на JSF предоставя лесен начин за постигане на съответствие между данните в модела и визулания изглед на данните. Пример: UISelectBoolean представлява checkbox и JSF позволява тази HTML компонента да бъде свързана с данни от тип Boolean.

Събитиен модел

Събитийният модел на JSF служи за прихващане на определени събития за определени компоненти и се състои от две части – събития (events) и обработчици (listeners). Event обектът идентифицира компонентата, от която е възникнал и носи информация за конкретното събитие. За да бъде уведомено за конкретно събитие, приложението трябва да предостави Listener клас. Този Listener клас има метод с определена сигнатура, който се извиква когато съответното събитие настъпи.

JSF предоставя няколко типа събития action event, value-change и data-model съответно за прихващане на събития от бутони и хиперлинкове, за прихващане на промяна на стойност на текстово поле, комбобокс, етц и за прихващане на промяна на данни на таблици и етц.

Обработвици на събития се ‘закачат’ по два начина:

• 
  Имплементиране на ActionListener или ValueChangeListener и добавяне а вътрешен таг за съответната компонента (actionListener или valueChangeListener)
  
• 
  Имплементиране на метод на backing bean и достъпване на този метод чрез атрибута actionListener
  

Валидационен модел

JSF предоставя както набор от готови валидатори, така и начини за извършване на собствена валидация. Отново има два начина за извършване на собствена валидация – чрез имплементиране на класа Validator и чрез използване на атрибута validator за референсване на метод на backing bean.

inputText ... validator="#{someBean.validateSometing}>

JSF навигационен модел

В JSF навигацията представлява набор от навигационни правила с навигационни случаи посочващи страницата, която ще се покаже на потребителя след натискането на бутон или хиперлинк.

Както показахме в примерното приложение, най-лесният начин за преход от една страница към друга е чрез статично дефиниране на атрибута action на commandButton или commandLink.

В реалния живот обаче не е толкова лесно и се налага динамично определяне на следващата страница. Това става с помощта на action метод дефиниран в backing bean. Този метод трябва да е без параметри и да връща String, който низ се използва за навигация до следващата страница чрез навигационните правила.

Ето как изглежда формата и как се референсва навигационен метод:

Ето как изглежда метода в SomeBean:

public String navigate() { if (this.value.length() > 5) { return "morethan"; } else { return "lessthan"; } }

И съответните навигационни правила:

/index.jsp morethan /morethan5.html lessthan /lessthan5.html

JSF backing bean модел

Не на последно място стои backing bean модела позволяващ динамична навигация, валидация, конвертиране, обработване на събития, свързване на текуща стойност на HTML компонента и свързване на HTML компонента към UIComponent клас за манипулация на състоянието и.

Демонстрация на binding

JSF жизнен цикъл

В основата си жизнения цикъл на едно JSF приложение е същия като този на JSP приложение – клиентът изпраща заявка и сървъра връща страница, преобразувана до HTML. За да поддържа сложния компонентен модел JSF разделя този цикъл на фази, всяка изпълняваща собствена роля. Тези фази са:

Restore View Phase. Първата фаза инициирана от FacesServlet се грижи за построяване (ако не е построено) на view дървото от компоненти (UIComponentBase), свързва валидаторите и обработяиците на събития за тези компоненти и записва това дърво във FacesContext инстанцията, която е достъпна от цялото приложение.

Apply Request Values Phase се грижи за извличането на новите стойности на компонентите.

Process Validations Phase се грижи за валидирането на извлечените стойности на компонентите.

Update Model Values Phase се грижи за свързването на компонентите от view дървото с техните валидни стойности.

Invoke Application Phase извиква всички обработчици за възникналите събития, навигационните методи и т.н.

Render Response Phase рендерира страницата подавайки я на JSP контейнера, който я свежда до HTML и я връща на клиента. Тук се попълват всички съобщение за грешки които трябва да се покажат на клиента.

жүктеу/скачать 115.5 Kb.

Достарыңызбен бөлісу: