17 komentáře “K čemu je nám užitečný komponentový web framework?

  1. Já už jsem teda frontend léta nedělal. Ale pořád mám dobré vzpomínky na komponentové frameworky jako je Wicket nebo Flex. A taky si pamatuju trápení s JSF/RichFaces a problémy s AJAXem.

    A to jsme byli v o dost jednodušší situaci, protože jsme řešili design a reuse jenom v rámci jednoho projektu. Takže si myslím, že vaše „komponentová cesta“ vede správným směrem.

    Na druhou stranu, u komponentového frameworku je potřeba „udržet míru“. Třeba použít GWT bych se docela obával – tam mi to přijde jako už moc velká magie.

    • No ono okolo komponentových frameworků panuje celá řada předsudků – zrovna včera jsme to probírali na NerdDinner. Obecně panuje názor, že komponentový framework musí být stateful, že je na složení HTML je potřeba mít odpovídající strukturu (která DOM +/- kopíruje) komponentového stromu (tj. např. že pro vykreslení tabulky je potřeba komponenta tabulka v ní nutně komponenty pro sloupce), že je nutné při každém requestu znova vytvářet strom komponent na straně serveru (i kvůli aktualizaci jediného údaje v jedné komponentě) atd.

      Tohle všechno jsou IMHO jen důsledky špatné implementace, nikoliv vlastnosti komponentového návrhu obecně.

  2. Díky všem za náměty – tyhle web frameworky, ty byly vždycky kontroverzní 🙂

    Každopádně, i když působím zatvrzele vážím si Vašich názorů.

  3. Sranda, jak se vy (s Javou, ale to asi není moc podstatné) pomalu dostáváte k principu fungování ala ASP.NET Web Forms, zatímco .NETisti se pomalu ale jistě přesouvají k MVC.

    Jinak mi připadá, že MVC hodně hájí lidi, kteří dělají spíš *weby* (ok, třeba mnohastránkové, komplikované, ale stále weby), zatímco vy budujete dost komplikovanou modulární *aplikaci*. Ačkoliv lze nepochybně v komponentovém frameworku dělat i weby a v MVC aplikace, obráceně je to přirozenější. Takže ve vašem případě se vůbec nedivím, že jsi z komponentového přístupu nadšený.

    • Mimochodem to mi přijde jako jeden z nejpřekvapivějších rozdílů mezi javisty a .netisty – zatímco javisti tíhnou ke komponentově orientovaným frameworkům, .netisti k MVC. Důvody můžeme rozebrat u piva:))

    • No člověk utíká od toho s čím udělal špatnou zkušenost 🙂 … a tady je vidět, že stříbrná kulka neexistuje.

      Ne, já proti push MVC nic nemám – na běžné aplikace jsou ideální. Nám prostě jen přestaly stačit. Pokud se v push MVC dá nějaký reuse udělat, tak jen v rámci jednoho projektu. My děláme desítky projektů ročně – od nejmenších až po ty velké a rozhodli jsme se jít modulární architekturou, která nám umožňuje sdílet kód napříč projekty docela efektivně. A tam bylo s push MVC trápení – furt jsme plno věcí psali znovu a znovu.

      Teď jsme schopni pouhým „zapnutím“ modulu nahodit celé nové (administrační) GUI a zpropagovat udělátka na potřebná místa skrz systém pár řádky kódu. Pravda je, že to místy začíná být už docela složité domyslet všechny důsledky a zvolit nejvhodnější řešení, ale to za ušetření takové spousty kódu docela stojí.

      Btw. s tou složitou modulární aplikací se dělají i tyhle jednoduché weby (a kupodivu efektivně):

      http://www.supermanie.cz/
      http://blog.fg.cz/clanky/
      http://www.cez.cz/etarif/cs/uvod.html

  4. Na twitteru je ta diskuse fakt na pendrek 🙂

    Slovicko stateless jsem tam zamichal proto, ze dneska je pravidlo (potvrzovane vyjimkami), ze komponentovy framework je tezce stateful (session), zatimco obycejne MVC, jako treba Stripes, vetsinou neni. Mozna to bylo zavadejici, to je fakt…

    Kazdopadne zakladni myslenka byla ta, ze co popisujes, to skutecne neni o komponentovem vs. MVC, ale o tom, co pouzijes za „V“. Ja napriklad aktualne na svem soukromem projektu pouzivam https://github.com/cgrand/enlive a s tim se odvazim tvrdit, ze bych to same napsal. Dokonce klidne i 1:1 (pokud to chapu dobre tak, ze vyse uvedena XMLka jsou vlozena nekde do HTML v miste, kde ta komponenta ma byt). Pritom ale nepouzivam zadny „komponentovy“ framework a Enlive mam jako view vrstu v klasicke MVC app.

    A to me privadi jeste k AOP samotnemu: je to jen jeden zpusob, jak ortogonalni concerny resit v klasickem ciste objektovem svete. Jak uz jsem nakousnul na twitteru – AOP je v zasade berlicka jazyku, co nemaji funkce vyssiho radu 😉 Jinde se to da vyresit napr. knihovnami typu https://github.com/technomancy/robert-hooke, nicmene v zasade k tomu zadna knihovna potreba neni. Pak se takova vec i jednoduseji pasuje vsude mozne…

    Pak je tu samozrejme jeste argument treti cesty a to ten, ze server-side renderovani je uncool a „so 90s“ a ze to mas stejne mit cely napsany v Angularu! 🙂

    (k negativum AOP – celkem dost zprehlednuje situaci pouzivani 100% typesafe AOP v Jave EE 6, ty jejich interceptory… neohnes to tak brutalne jako pres stringovou definici pointcutu, ale je to relativne bezpecne a prehledne)

    • Vyžadování nenažraného state na straně serveru je nedokonalost frameworku, nikoliv obecná vlastnost komponentového přístupu. Ale souhlasím, že třeba JSF to třeba se stavovostí krutě přehnaly (jiné rámce neznám natolik, abych to mohl tvrdit).

      V ohledu XMLek – struktura komponent na stránce se drží odděleně od samotných HTML šablon. V podstatě podobně, jako to má Enlive – rozdíl je v tom, že šablony můžeme dle potřeby přetěžovat a také šabona se váže ke komponentě. Tj. nikde se nenajde kompletní HTML stránka od head až po konec body. HTML je rozpalcelované na jednotlivé komponenty, což nám umožňuje zmiňovaný partial update a další legrácky. Tohle je trošku o zvyk – člověk si musí zvyknout myslet „strukturovaně“ – ale v zásadě se to dá napasovat na jakékoliv HTML.

      Máš pravdu, že AOP je v jistém směru berlička – na druhou stranu v odkazovaném https://github.com/technomancy/robert-hooke mi uvedený příklad připadá to samé jako v AOP pointcut:

      (add-hook #’examine #’doubler)

      A AOP advice:

      (defn doubler [f & args]
      (apply f args)
      (apply f args))

      Jen je to forma jiného zápisu a jazyk se „nehackuje“ na úrovni byte-code, ale využívá se vlastnosti funkcionálního přístup. Nicméně, principielně mi to připadá dost podobné.

      Jo a s tím Angularem ještě uvidíme – zatím jsem na server side o dost produktivnější, než kluci s JavaScriptem 🙂

      • Teď jsi mě odkopal 🙂 … používáme vlastní. Je mi jasné, že se najde plno lidí, kteří by mě v tuto chvíli začali o hlavu omlacovat NIH, ale ono to vzniklo docela spontánně.

        Potřebovali jsme vyvinout něco, co by dokázali nasazovat naši webdevelopeři – což nejsou programátoři jako takoví, aby s tím dokázali dělat jednoduché formuláře na webech a nemuseli s tím ztrácet čas Javisti. A nakonec se to zvrhlo ve full blown web framework 🙂

        Každopádně účel nám to plní – my Javisti se věnujeme vývoji byznys logiky a níž, pak vytvoříme bridge „poskytovatelů dat“ a „akcí“ (což jsou ty kontrolery, které jen převolávají byznys logiku) a webdevelopeři to potom včetně HTML oživí na view vrstvě. Donutilo nás to i vytvořit supportní nástroje, které jsem u jiných frameworků ještě neviděl: http://blog.novoj.net/2012/09/04/nastroje-pro-vyvoj-web-aplikaci-ve-forrestu/

        Btw. třeba tohle: http://www.supermanie.cz/ … vyrobil kompletně kolega webař. Za mě je tam jen pár Groovy tříd na nějaké validace, akce bylo vymalováno. Vespod je nakonec znovupoužitelný modul na galerie napsaný v Javě.

        Podobně s tím třeba nás firemní systém poskládal externista, který je kvalitní databázista, ale s webem zatím moc velké zkušenosti neměl. My jsme mu připravili komponenty, kostru webu, napojení přes SOAP na jeho Sybase databázi (za nás investice několika málo týdnů) a on s tím za rok a půl vytvořil vcelku obstojnou nadstavbu nad krabicovým IS (aktuálně víc jak 40-50 unikátních stránek s reportingem, fakturací atp.)

        Kdybych nevěděl, že to funguje, tak to takhle neobhajuju 🙂

  5. Moc nerozumim kde je ten přínos komponent. V MVC budu reprezentovat stránkovanej výpis samozřejmě taky nějakym objektem, něco jako PagedList. View pak na jeho vyrenderování může použít *znovupoužitelnou* šablonu, která pomocí *reflexe* vygeneruje záhlaví umožňující sortování a filtraci. Rozdíl je v tom, že v MVC je čistý oddělení logiky (kde seberu PagedList) od zobrazení (šablony). Reuse je stejnej. Když to budu chtít exportovat do XLS, pošlu ten PagedList něčemu, co ho pomocí *reflexe* ztransformuje. No a na přidání novýho gadgetu do všech editorů stránek? Předpokládám že pokud maj všechny editory aspoň nějakou sdílenou funkcionalitu, bude tam někde šablona která bude všude použitá, takže ji prostě změnim a #epic #win.

    MVC neznamená že jsme zahodili reuse. Jen striktně oddělujeme práci s daty a jejich renderování.

    • Při psaní článku jsem se i já trošku zorientoval v pojmech. Oba mluvíme o MVC – i komponentové frameworky jsou MVC, komponentové jsou „pull“, nekomponentové jsou „push“ (viz. http://en.wikipedia.org/wiki/Web_application_framework) … a s tím bych souhlasil.

      Stojím si za tím, že v push rámcích máš daleko větší práci s reusem, protože ty tě k žádnému zapouzdření nevedou. Když si vezmu za příklad Strutsy nebo Spring, tak tam si controller osahá request (nebo mu framework zajistí binding), dotáže model, výsledky překouše a nacpe to jako atributy requestu. Všechny pěkně na jedné hromadě. Tady se moc o zapouzdřenosti, která vede ke znovupoužitelnosti, moc mluvit nedá.

      Ad tvoje argumentace – co by v tom případě bylo součástí toho PagedListu? Seznam sloupců odpovídající toho co je ve view? Identifikace sloupce, podle kterého je setříděno? Nastavení vstupních filtrů? A kdo ten PagedList vyrábí? Byznys vrstva? To asi ne, tím bys view zanášel do modelu. Takže výstup z byznys vrstvy překoušeš v kontroleru, přesypeš data z jedněch objektů do PagedListu, který tedy slouží jen jako DTO. To je krapet fuška řekl bych.

      Škoda, že tohle je moc hutné téma i na diskusi pod článkem. Tohle by chtělo probrat nad konkrétními případy – já prostě jen aktuálně cítím, jaké nám dává komponentová architektura možnosti. V push MVC modelu jsem toho udělal už hodně a nikdy jsem z toho nebyl tak spokojený, jako teď s tím co máme. Ale chápu, že to je těžko předatelné 🙁

      • Mluvim o „push“ MVC, protože „pull“ neni čistý MVC. Za čistý MVC považuju, když controller sežene všechny data potřebný pro stránku a view to „jen“ renderuje, a pokud je složený z více šablon, stále jsou šablony relativně hloupý a dělaj maximálně různý transformace dat který dostanou, ale rozhodně nemůžou třeba šahat na databázi.

        PagedList obsahuje data (řádky) a metadata (seznam sloupců, sort, filtry). Jestli jsou metadata definovaný staticky (a dostaneš se k nim reflexí) nebo explicitně je celkem fuk. Tyhle informace ti *musí* dát byznys vrstva, protože pokud chceš efektivně stránkovat (=na straně databáze), pak jí to musíš předat v rámci dotazu.

        DTO je super věc, pokud chceš čistě oddělit vrstvy. Vytvářet a plnit je můžeš nějak automaticky. Pro view je navíc dobrý si vytvořit display objects, pokud je to nutný. Když to shrnu:

        1. Controller zavolá remote facade
        2. Remote facade pracuje s business vrstvou, zeptá se jí na objekty a přeloží je do DTO, který vrátí controlleru
        3. Controller buď jen předá DTO do view, nebo pokud vyžaduje zobrazení nějakou logiku, tak nejdřív přeloží DTO na Display Object a ten pošle view.

        Vypadá to jako „spoustu práce“ ale na velkejch projektech to má jednoznačnej benefit – vrstvy jsou maximálně decoupled, krásně se to testuje, máš jasný rozhraní.

        A že controller překouše data „všechny pěkně na jedné hromadě“? To nemusí bejt pravda, záleží jak to napíšeš:) V controllerech je možný provádět určitou kompozici dat a je to vrstva kde je možný bejt hodně kreativní;)

      • Pull MVC model nijak nešpiní – šablony zůstávají hloupé (my např. používáme FreeMarker a jedno stěžejních prohlášení je, že je stavěný tak, aby neumožňoval dělat složité věci v šablonách) – viz. What is FreeMarker zde: http://freemarker.sourceforge.net/

        Jde jen o to, že pull MVC definuje komponentu jako něco, co v sobě spojuje view a část controlleru. A přesně o té sdílení části controlleru nám jde. Java kód komponenty, návazné akce, které něco mohou provádět a poskytovatelé dat reprezentují v tomto směru C. Kupříkladu akce nebo poskytovatelé dat taky nesmí přímo provádět nějakou byznys logiku – ty jen přetransformují požadavky z view na volání byznys vrstvy, kde se děje všechno důležité – reprezentují jen takový bridge do byznys vyrstvy, která je view agnostická.

        Princip překladu volání do byznys vrstvy, který uvádíš chápu – takhle jsme to dělali. Mě ale kreativita a snaha o reuse v controller vrstvě dovedla do komponentové architektury 🙂

      • @Dan: Do diskuse cisty / necisty bych se moc nepoustel, protoze interpretaci MVC je milion a nerekl bych, ze existuje jedina svata… Reenskaug, kdyz poprve MVC privedl na svet, tak mluvil o pull. Ukolem C nebylo dotlacit data do V. Bylo to ale samozrejme tehdy v pripade desktopu, coz je ale taky tak trochu to, co se komponentove web. frameworky snazi emulovat… takze bacha, zauberre rasse MVC tady v zasade dela Honza 😀

        Co se tyka tvych popisovanych 3 bodu, tak samozrejme treba v pripade SOA to ani moc jinak nejde. Jinak jsem ale az prilis casto videl aplikace, ktere byly psane timhle zpusobem a zvrhly se v proceduralni lasagne, ve kterych anemicky objekty litaly nahoru dolu servisama, do kterych zgravitovala veskera business logika aplikace… O OOP se uz pak moc neda mluvit, o FP ale taky ne… Nemam rad prekladani mezi DTO na kazdym myslitelnym spoji v aplikaci. Kdyz jsou ruzne vrstvy zavisle na spolecnem domenovam modelu, mezi nimi samotnymi to zadnou zavislost nedela (pokud programator neni überprase). Decoupling a cisty rozhrani zustava…

Napsat komentář