Cesta požadavku útrobami Spring MVC

Každý požadavek (objekt typu javax.servlet.http.HttpServletRequest), který DispatcherServlet přijme, je zpracován následujícím způsobem:

  1. Do atributu s názvem DispatcherServlet.WEB_APPLICATION_CONTEXT_ATTRIBUTE požadavku je umístěn aplikační kontext daného servletu. Zde je k dispozici pro potřeby dalších objektů podílejících se na životním cyklu požadavku.

  2. Jako atribut je do objektu požadavku přidán detektor národního prostředí, tedy objekt implementující rozhraní org.springframework.web.servlet.LocaleResolver, který je dalšími prvky procesu využíván k rozpoznání národního prostředí (Locale) klienta. V aplikačním kontextu musí být definován pod názvem localeResolver. Nevyskytuje-li se tam taková definice, je vytvořena a použita instance třídy org.springframework.web.servlet.i18n.AcceptHeaderLocaleResolver.

  3. Jako atribut je do objektu požadavku přidán detektor motivu, tedy objekt implementující rozhraní org.springframework.web.servlet.ThemeResolver, který je dalšími prvky procesu využíván k identifikaci individuálních uživatelských nastavení, tzv. motivů (themes). V aplikačním kontextu musí být definován pod názvem themeResolver. Defaultní implementací je org.springframework.web.servlet.theme.FixedThemeResolver.

  4. Je-li v aplikačním kontextu definován objekt s názvem multipartResolver (implementující rozhraní org.springframework.web.multipart.MultipartResolver), objekt požadavku je zabalen do objektu implementujícího rozhraní org.springframework.web.multipart.MultipartHttpSertvletRequest. Takto je dalším článkům řetězu usnadněna práce se soubory, které uživatel posílá serveru. Nevyskytuje-li se v kontextu objekt s daným názvem, požadavek není nijak ovlivněn.

  5. V aplikačním kontextu jsou vyhledány všechny objekty typu org.springframework.web.servlet.HandlerMapping a v definovaném pořadí jsou dotázány na kontroler, který požadavek zpracuje, a na interceptor, který provede předzpracování a postzpracování požadavku. Neobsahuje-li aplikační kontext žádný objekt třídy HandlerMapping, vytvoří se instance třídy org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping.

  6. Požadavek je předán interceptoru, byl-li nějaký vybrán, a ten provede předzpracování požadavku před tím, než je předán kontroleru. Interceptor může provést libovolnou akci, např. přesměrovat požadavek jinam, a zabránit tak normálnímu pokračování řetězu zpracování.

  7. V aplikačním kontextu je vyhledán objekt typu org.springframework.web.servlet.HandlerAdapter a požadavek je mu předán. Konkrétní implementace tohoto rozhraní určuje, jaký typ kontroleru bude použit v dalším kroku. Účelem existence tohoto rozhraní v procesu zpracování požadavku je možnost snadné výměny Spring MVC™ rámce za jiný s jiným typem kontrolerů, případě libovolné úpravy způsobu doručení požadavku kontrolerům. HandlerAdapter je v aplikačním kontextu vyhledán na základě svého typu, název jeho definice může být libovolný. Defaultní implementací je org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter, který podporuje kontrolery Spring MVC™ implementující rozhraní org.springframework.web.servlet.mvc.Controller.

  8. Požadavek je předán vybranému kontroleru ke zpracování. Kontroler vytvoří model ve spolupráci s aplikační vrstvou aplikace a určí logický název pohledu, který bude pro zobrazení modelu použit. Obojí předá dál.

  9. Požadavek je znovu zpracován interceptorem, byl-li nějaký vybrán.

  10. V aplikačním kontextu jsou vyhledány všechny detektory pohledu, tedy objekty typu org.springframework.web.servlet.ViewResolver, které mají za úkol převést logický název pohledu na konkrétní cestu k souboru, který zobrazení provede. Logický název pohledu vrácený kontrolerem je jim předložen v definovaném pořadí, při čemž první úspěšný detektor pohledu přeruší řetěz a vrátí výsledek. V typickém případě, kdy se pro zobrazení používá nějaká šablonovací technologie (JSP, FreeMarker™, Velocity), je konkrétním pohledem právě šablona daného jazyka.

  11. Získaný model je zobrazen prostřednictvím konkrétního pohledu.

Na popsaném procesu je vidět důsledné dodržování pravidla o používání rozhraní místo konkrétních implementací (programování do rozhraní). Spring™ tak poskytuje v podstatě nekonečné možnosti rozšiřitelnosti, protože libovolný krok procesu lze upravit implementací příslušného rozhraní, které se procesu účastní, a registrací dané konkrétní třídy v aplikačním kontextu. Mnohé užitečné implementace zmíněných rozhraní už však obsahuje samotný Spring™, takže úpravu chování procesu zpracování požadavku lze provést pouhou konfigurací v aplikačním kontextu daného servletu.

Nelekejte se množství rozhraní a tříd, které zde byly zmíněny, podrobnější vysvětlení je teprve před námi. Pojďme se teď stručně na některé konkrétní třídy jednotlivých typů podívat.

Komentáře

Téma neobsahuje žádné komentáře.

Vložit komentář

Můžete používat značkovací jazyk Texy!


Jméno:
E-mail:
Url:
Komentář:
1 + 2 =
 
MoroSystems, s.r.o.