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



Дата23.03.2017
Размер158.96 Kb.

JavaServer Faces

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

Въведение


Един от компонентите на Java Enterprise Edition е JavaServer Faces технологията. Това е фреймуърк за разработване на уеб приложения базиран на JSP и Java Servlets технологиите.

Началото на JSF е поставено през 2001 година с JSR 127 (Java Specification Request). През 2004 година излизат на бял свят версиите 1.0 и 1.1. Оказва се обаче, че JSF има архитектурни проблеми и се налага изготвянето на нова спецификация – JSR 252. Това е подобрение на JSF 1.1 и резултатът е JSF 1.2, което излиза през 2006 година. Тези спецификации са подкрепени от фирмите: Apache Foundation, IBM, Oracle, Sun Microsystems.

JavaServer Faces технологията се състои от две основни части:


    • API за представяне на HTML компоненти (бутони, хипер-ликове, таблици) и управляване на тяхното състояние, обработка на събития, валидация от страна на сървъра, навигация между страниците, интернационализация, автоматично преобразуване между типовете.

    • Две таг-библиотеки за изграждане на потребителски интерфейс в JSP страница и за свързването на съответните HTML компоненти със сървърни обекти, предоставящи логиката на приложението.

Защо JSF? (Преимущества)


JSF имплементира MVC (Model-View-Controller) дизайн шаблонът, като ясно разделя бизнес логиката от презентационната част. Това носи със себе си няколко ползи:

    • Позволява да третирате HTTP заявка като събитие, специфично за дадена компонента (бутон, хиперлинк, етц)

    • Позволява ясно разделение на отговорностите в един екип, разработващ Уеб приложение с JSF. Например един разработчик на уеб страницата (page author) може да се фокусира върху съдържанието и изгледа и без да има опит в програмирането. Той работи само с таговете от JSF библиотеките и свързва съответните компоненти със сървърни обекти (валидатори, конвертери, обработчици на събития и т.н. managed/backing beans, които дефинират логиката на приложението) и не му се налага да знае нищо за бизнес логиката. Програмистът на бизнес логиката пък дефинира навигацията, логиката (валидация на форми, предаване на данни) и не му се налага да знае нищо за конкретния изглед на страницата (стилове, разположение на компонентите). Той управлява състоянието на копонентите, валидира ги.

    • Позволява използване на средства за визуално програмиране (RAD, WYSIWYG) подобно на ASP.NET. Модела на разработка наподобява Swing програмиране.

JSF използва JSP за презентационната си част и това позволява JSF да се използва с други технологии като JSTL, Struts.

Едно от преимуществата на MVC е, че е възможно да се смени изгледа (View) без да се променя модела (Model). JSF позволява една компонента да се рендерира по различни начини и по този начин позволява едно приложение да е достъпно от различни клиенти (Web browser, PDA).



Пример: Имаме форма, която трябва да се submit-не. JSF позволява да направим това по два начина: с бутон Submit или с хипер линк. Двете компоненти правят едно и също, следователно имат една и съща функционалност и съответно са представени с един и същ клас, който се грижи за състоянието им (UICommand). Разликата е, че трябва да изглеждат по различни начини: и

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


Какво представлява едно JSF приложение? (Структура)


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

    • Набор от JSP страници.

    • Набор от backing beans, които представляват JavaBeans дефиниращи свойства и функции за компонентите на страницата.

    • JSF конфигурационен файл (faces-config.xml), описващ и конфигуриращ използваните backing beans (id, клас, scope), описващ правилата за навигация, всякакви потребителски обекти като собствени валидатори и компоненти.

    • Деплоймънт дескриптор (web.xml)

    • Евентуално класовете за собствени валидатори и конвертери (не стандартните, които JSF предлага), за собствени копоненти и таговете към тях, обработчици на събития.

    • Както всяко Уеб приложение, трябва да включва и таг-библиотеки като jar файлове.

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


Ще демонстрираме съвсем просто JSF приложение, приемащо произволно име за параметър и след натискане на бутона “Hello” се зарежда страница с надпис Hello с подаденото име.

Стъпки:

    • Мапване на FacesServlet в web.xml.

    • Създаване на страниците използвайки основните JSF тагове и тези за HTML компонентите.

    • Свързваме данните от първата страница с backing bean.

    • Дефинираме навигацията между страниците във faces-config.xml.

    • Построяваме backing beans и ги декларираме нашите backing beans в faces-config.xml.

Мапване на FacesServlet в web.xml

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





FacesServlet

FacesServlet

javax.faces.webapp.FacesServlet

1





FacesServlet

/faces/*



Т.е всички заявки със стринга /faces ще се обработват от FacesServlet.

Създаване на страниците използвайки основните JSF тагове и тези за HTML компонентите

Създаваме страницата 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 приложение, всяка страница е представена като дърво от компоненти. Добавяме тагът за да обозначим коренът на това дърво. Т.е всички останали компоненти трябва да се намират вътре в този таг.

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





Тагът се рендерира като текст със съответната стойност. В случая, тази стойност се взима от файлът text.properties.

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





Всички компоненти, чиито стойности искаме да изпратим към сървъра със изпращане на POST заявката, трябва да са в този таг.

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













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



,







Свързваме данните от полето за въвеждане на име със съответния backing bean.

Приложението се състои от две части – в първата въвеждаме име, във втората показваме това име. Трябва ни начин да запазим стойността, която сме въвели в първата страница и да покажем тази стойност във втората. Това се постига с т.н. 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 и го декларираме във faces-config.xml

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



package com.dreamix.jsf;

public class PersonBean {

private String name;

public String getName() {

return name;

}

public void setName(String name) {

this.name = name;

}

}

Декларираме PersonBean във faces-config.xml по следния начин:



PersonBean

com.dreamix.jsf.PersonBean

request



определя името на 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 и я връща на клиента. Тук се попълват всички съобщение за грешки които трябва да се покажат на клиента.


База данных защищена авторским правом ©obuch.info 2016
отнасят до администрацията

    Начална страница