Názory k článku Cocoon v příkladech: Flowscript, Continuations a MVC+

  • Článek je starý, nové názory již nelze přidávat.
  • 21. 1. 2004 9:17

    Michal Krause (neregistrovaný)

    Nerozumím úplně přesně formulaci, že se díky Continuations lze obejít bez cookies nebo session ID. Jestli jsem to dobře pochopil, použití ${continuation.id} v odkazech děla v podstatě přesně to samé, jako "normální" session ID, ne?

  • 21. 1. 2004 9:56

    Pavel Sykora (neregistrovaný)

    Continuation ID (ContID) dela toho o neco vic. Session ID definuje jen session, kdezto ContID je jedinecne pro kombinaci session + misto, kde se zastavil flowscript. Jinymi slovy, ContID neni pro session konstantni jako session ID a tim padem definuje krome vlastni session i stav aplikace pro danou session. Tim se i pouziti ContID v odkazech bude mirne lisit od pouziti session ID (samotne session ID nedefinuje stavy aplikace, musi se tam pridat dalsi informace).

    Samozrejme, identifikace session musi byt pouzita nekde uvnitr Cocoonu. Vyvojari webove aplikace se session ID ale nemuseji zabyvat.

  • 21. 1. 2004 10:05

    martin kavalec (neregistrovaný)

    a navic si (na rozdil od session ID) musim continuation.id explicitne predavat v sablonach pres URL a ve flowscriptu si jej zase vyzvedavat, coz u session nemusim)

    Dovedu si dobre predstavit, jak to funguje, dokud uzivatel v jednotlivych requestech odesila data z formularu a rizeni toku logicky probiha az na serveru (podle toho co uzivatel odesle).

    Jak se ale resi situace, kdy uzivatel muze vyplnit formular, ale nemusi. Napr. mam diskuzni forum kde je rovnou formular pro poslani prispevku, ale taky X linku na jina temata a da se cekat, ze uzivatel spis pujde cist dalsi prispevky, nez ze bude neco psat. Fce sendPageAndWait se pak vstupu vetsinou nedocka. Budou se mi pak na serveru mnozit cekajici Continuations z techto neodeslanych formularu? (co kdyby uzivatel klikl na Back a rozhodl se, ze neco prece jenom napise?)

    Podobne, co se deje, kdyz mam na strance formularu vice a uzivatel si muze vybrat, ktery z nich pouzije? (jako napr. tady na rootu - muzu vyhledavat, zaregistrovat si odber novinek, ted dokonce jeste odeslat tento prispevek a taky mam moznost neposilat nic a pokracovat ve cteni clanku)

  • 21. 1. 2004 10:10

    martin kavalec (neregistrovaný)

    Zatimco jsem psal prispevek, dostal jsem odpoved ohledne predavani contID a jeho vztaho k session ID, ale zbyvajici 2 otazky me stale zajimaji :)

    Kazdopadne dik za serial o Cocoonu, je dobre si rozsirovat obzory o jine pristupy k reseni webovych aplikaci.

  • 21. 1. 2004 11:15

    Pavel Sykora (neregistrovaný)

    Continuations jsou na serveru postupne ukladany bez ohledu na to, zda uzivatel formular odesle ci ne. Jedna se vsak o relativne nenarocne objekty, takze by s tim nemel byt problem (osobne jsem to vsak netestoval). Continuations jsou na serveru proste jen ulozeny, pouziti terminu "cekajici" ve mne trosku vzbuzuje dojem, ze se zastavi vlakno zpracovavajici pozadavek, tomu ale tak neni. Objekty expiruji casem (nebo manualne, pokud chci, aby se k danemu stavu aplikace nedalo vratit - napriklad po commitu do databaze).

    Pokud je tok stranek primy, tak si vlastne ani zadne ContID predavat sablonou nemusim. To je spise potreba, pokud si chci "odskocit" nekam jinam a pak se vratit do puvodniho mista a stavu aplikace. Je to vlastne i v tom prikladu. V prvnim okne mohu postupne nekolikrat pridavat do objednavky, ale kdykoliv si mohu "odskocit" podivat se na obsah kosiku, a pak se k objednavani zase vratit do toho mista, kde jsem "tok stranek" objednavani (coz je cyklus volajici porad dokola tu samou stranku) opustil.

    Vice formularu na strance, prerusovani cinnosti, tlacitko "Back" atd. neni pro Continuations problemem. Muj nazor je, ze takovyto slozity tok stranek lze jimi naopak naprogramovat vyrazne jednoduseji, nez klasickymi prostredky.

    Pouziti Continuations napriklad umoznuje, aby po loginu uzivatel klonoval okno a pokracoval v obou oknech nezavisle (pokud je ovsem v dane aplikaci takova funcionalita vhodna). Continuations se pak na serveru ukladaji jako strom. Pomoci sessions by se takova funkcionalita patrne programovala obtizne.

  • 23. 1. 2004 13:25

    Jan Kovar (neregistrovaný)

    Bohuzel tim ze ulozite stav aplikace na serveru, nebudou vase stranky bookmarkovatelne. Vytvorite-li tedy timto zpusobem napriklad internetovy obchod, coz je takovy mix mezi anonymnim / autorizovanym webem, nebude si navstevnik moci ulozit stranku s nejakym produktem do "oblibenych" ani poslat zkusenejsimu kamaradovi odkaz na tenhle produkt s zadosti o radu. Co je horsi, odriznete uplne vyhledavace, nebot vase url budou platne pouze pro jednu session. A to by zvlaste v pripade internetoveho obchodu mohlo vadit :-)
    Pokud toto cocoon nejak resi nebo sem neco spatne pochopil, predem dekuji za opravu.