Tvorba komponent na projekte ITMS2014+

Na projekte ITMS2014+ sme na tvorbu používateľského webového prostredia (UI) použili framework Java Wicket (link: https://wicket.apache.org/). Bližie informácie na základe ktorých sme sa rozhodli použiť práve tento framework nájdete v tomto blogu.

Špecifikom tohto projektu bola obzvlášť veľká početnosť komplexných obrazoviek. Na začiatku bolo potrebné zaviesť určitú typizáciu obrazoviek, vytvoriť katalóg komponent, navrhnúť schému skladania komponent do komplexnejších celkov a dbať o čo najväčšiu mieru zapuzdrenia komponent s jasne definovaným API. Navrhnúť vhodnú mieru granularity zapuzdrenia komponent na začiatku projektu nie je vôbec jednoduché, nakoľko sme vystavený dvom potencionálnym rizikám:

1. komponenty nedostatočne zapuzdríme

• vytvára to priestor pre vznik novotvarov, nerešpektovanie nastavených štandardov
• v prípade refaktoru nemamáme ucelnú komponentu pod kontrolou
• zvyšuje sa chybovosť
• stažuje sa testovateľnosť
• zvyšuje sa neprehľadnosť kódu

2. komponenty zapuzdríme až moc

• v prípade neustabilizovaných požiadaviek dochádza k častým úpravam
• vzniká viacero samostatných komponent, ktoré by bolo možné vytvoriť kompozíciou z granulárne menších komponent, častokrát sa duplikuje kód a uplatňuje copy-paste
• aj malé výnimky spôsobujú veľké komplikácie a prerábky, ktoré následne vedú k vyššej chybovosti
• nižšia zrozumiteľnosť a čitateľnosť komponent

To, akú mieru zapúzdrenia klientských komponent na danom projekte zvoliť, závisí hlavne od úrovne poznania navrhovaného UI, tímu, ktorý bude obrazovky implementovať a rizika nutnosti vačších prerábok. Na projekte ITMS2014+ boli rozhodujúce faktory pre určenie miery granularity zapuzdrenia komponent používateľského rohrania nasledovné:

• vyvojový tím - zložený z programátorov s nízkou mierou poznania tvorby webového používateľského prostredia (HTTP, HTML, CSS, JS, AJAX atď)
• vysoké riziko rozsiahlych prerábok používateľského rozhrania (preskupovanie prvkov na obrazovke, viacnásobný redizajn)

Aby sme elminovali riziká vyplývajúce z miery granularity zapuzdrenia komponent popri rizikách vyplývajúcich z vlastností projektu, zvolili sme postup mikrogranularity komponent s následnou kompozíciou do vačších celkov. Komponenty sme vyčlenili do samostatnej knižnice, ktorú sme spravovali podľa prichádzajúcich požiadaviek.

Príklad takejto kompozícíe uvediem na štandardnej formulárovej obrazovke projektu. Príklad je pre názornosť umelo zjednodušený, nakoľko sa nejedná len o samotné spájanie komponetov do väčších celkov, ale zapuzdruje sa hlavne logika chovania komponent.

Na najnižšej úrovmi granularity figuruje komponenta TextField, ktorú dodáva framework Wicket. My sme ju rozšírili o ďalšie vlastnosti a vytvorili sme si vlastnú komponentu s názvom TextFieldComponent. Z predchádzajúceho obrázka je vidno, že pred každou formulárovou komponentou je popisok, ktorý pomenúvavá dané formulárové pole. Tak vytvárame ďalšiu komponentu s názvom FcText (Form Component Text), ktorú okrem iného vytvoríme kompozíciou komponent Label a TextFieldComponent. Takto vytvorenú komponentu zasadzujeme do formulára, ktorý sa nachádza na formulárovej obrazovke, ktorá prdstavuje komponentu najvyššej granularity.

Úroveň zapuzdrenia na projekte ITMS2014+ sme posunuli ešte ďalej tým, že sme po vzore Swingu vytvorili základné formy layout managerov, ktoré prislúchajú jednotlivým sekciám, napr.:

• sekcia ovládacích tlačidiel je realizovaná prostredníctvom FlowLayoutu (ukladá prvky za sebou)
• formulár je zastrešený GridLayoutom (ukladá prvky do definovanej mriežky/matice)

Koncového programátora sme od použitého layout managera odstrešili tak, že pracuje len s rozhraním Container, ktoré mu bez hlbšej znalosti umožňuje vkladať komponenty do danej sekcie spôsobom, ktorý zodpovedá definvanému štandardu UI, bez nutnosti použiť HTML kód.

Hlavné výhody tohto prístupu sú:

• stačí malá skupina expertov (na projekte ITMS2014+ s vyše 1000 obrazovkami jeden expert) na webové UI, ostatní členovia tímu nemusia mať znalosti z tvorby webových UI (HTML, CSS, JS), aj napriek tomu sú schopní samostatne vytvárať komplexné obrazovky
• realizovanie malých aj rozsiahlych refaktorov nie je problém (na projekte ITMS2014+ sme po troch rokoch programovania sme robili rozsiahly refaktor, rozloženia komponent vrátane grafických prerábok)
• kompilačné závislosti komponent

V niektorých z ďalšich blogov detailne popíšem návrh a implementáciu layout managerov vo frameworku Apache Wicket.