- Z tego, na ile pamiętam JSFy, to od którejś wersji JSF można bylo dać adnotację
@FacesConverter
i zadeklarować albo jego id w atrybucie value
, albo zadeklarować dla jakiej klasy Java ten konwerter będzie używany forClass
.
- Na komponencie JSF można było chyba wskazać
<f:converter converterId=""/>
.
Odnośnie połączenia z DB, od bodajże JSF 2.3 CDI jest wspierane w Converterach. Wówczas można zainjectować tam swoje Repository czy jakieś DAO.
EDIT: We wcześniejszych wersjach można to zrobić hackiem - CDI.current().select(MyRepository.class).get()
, tylko trzeba pamiętać, że wiąże się to z zabawą z cyklem życia beanów.
Generalnie, mogę powiedzieć, że jak się projekt rozrośnie i robi się większy zespół, to bardzo fajnie się potem utrzymuje taką aplikację, w której liczba konwerterów robi się spora (najlepiej tych forClass
) :)
I w ogóle nie polecam używania JSF. Do frontu jest wiele lepszych frameworków, a JSF to tak naprawdę dość skomplikowany framework, gdzie dzieje się dużo magii.
Ostatnio styczność z JSF miałem jakieś 1.5-2 lata temu i muszę przyznać, że jest to chyba jedyna technologia "frontowa", w której tak bohatersko walczyłem z problemami, których w normalnym frontowym frameworku nie ma.
Bardzo fajnie w JSF tworzy się i używa generycznych, reużywalnych komponentów. Już dokładnie nie pamiętam szczegółów, ale np. reużywalność w tym samym formie wielu composite-components potrafiło rodzić jakieś błedy. Potem jakieś hacki, jakaś zabawa z np. <h:form prependId="false"/>
.
Bardzo fajnie pisze się renderery do komponentów (sklejanie HTML w Javie, to już może od razu zwracajmy cały HTML z backendu - pewnie nawet byłoby prościej).
EDIT:
Btw. jeśli już bardzo chcesz coś robić w JSF, polecam zerknąć na BalusC - Debug JSF Lifecycle (btw. chba 90% odpowiedzi na SO dot. JSF jest autorstwa tego pana). :)