Reprezentace velmi podobných procesů více presentery

dcepelik

Pěkný večer,

potýkám se s tzv. problémem na úrovni (problém, jehož řešení není zcela zřejmé). Uvažujme složitější e-shop. Výběr zboží a jeho přidání do košíku funguje standardním způsobem, cesty uživatelů se však liší při objednávce.

Neregistrovaní uživatelé musí vyplnit fakturační a doručovací adresu.
Registrovanému uživateli fakturační a doručovací adresu předvyplníme. Protože jej nechceme obtěžovat, krok „Fakturační a doručovací adresa“ zcela přeskočíme. (Adresy může upravit v předposledním kroku před závaznou objednávkou.)
Práci usnadníme také uživatelům se slevovým kuponem. Předvyplníme jim adresu, ale protože u nás možná nakupují poprvé, raději jim zobrazíme krok „Fakturační a doručovací adresa“, protože se od doby, kdy jsme vystavili kupon, mohla změnit. Protože tito uživatelé dostávají slevu, musí povinně přispět Nette Foundation libovolnou nenulovou částkou.

Nastává otázka, jak tyto „cesty“ realizovat v praxi. Zdá se mi, že realizovat proces nákupu (tj. vlastního nákupu zboží, nikoli jeho výběru) pomocí jediného presenteru je nevhodné, neboť:

by presentery musely udržovat složitý vnitřní stav (kterým krokem uživatel už prošel, kterým ještě ne, zda krokem musí či nemusí projít),
stejná URL by měla více významů (jediný způsob, jak v presenteru určit, kterou „cestou“ se uživatel vydává, je z kroků, kterými již prošel).

Spletitost kódu takového presenteru roste neúměrně složitosti „cesty“. Přesněji roste se čtvercem složitosti. (Nebo možná s krychlí, když je člověk pesimista.)

Jako vhodnější řešení se proto nabízí použití různých presenterů se společným předkem, jeden presenter pro každou „cestu“. Odpadnou složité podmínky v akcích, sníží se počet potřebných přesměrování a forwardů, URL bude mít vždy jeden význam. K duplikaci logiky nedojde, protože bude definována ve třídě předka. Pokud se šablony kroků liší s ohledem na „cestu“, snadno se s tím vypořádám (prostě vytvořím zvláštní šablony pro daný presenter, kterými překryji či rozšířím ty obecnější).

Návrh se také daleko lépe vypořádá se změnou, budu-li chtít přidat další „cestu“ (nepřidávám podmínkové konstrukce, ale nový presenter).

Vzniknou však poněkud zvláštní (a velmi jednoduché) presentery s ještě zvláštnějšími názvy. A celé se mi to vůbec zdá dosti neortodoxní, a tedy se ptám na názor širšího obecenstva. Zda je to hnus, zda je to geniální či to lze udělat jinak a třeba mnohem lépe?

Jsem vděčný za všechny podněty. (Logiku výše vykonstruovaného případu prosím neuvažujte.)

Editoval dcepelik (17. 9. 2011 23:43)

22

Nevím, co v tom hledáš za složitost? Všechno obslouží v klidu jeden presenter s více view, maximálně ve spolupráci s nějakou/nějakými komponentami

neregistrovaný je odkopnut na registraci nebo data formuláře se nevyplní, pokud nejsou v session
registrovanému uživateli se data natáhnou z DB. V krokovém formuláři jedno view přeskočíš

Editoval 22 (18. 9. 2011 0:50)

Filip Procházka

Osobně dávám přednost více presenterům s co nejméně pohledy, ideálně jedním.

Co se týče tvého problému, myslím, že v tom hledáš moc vědu :) Většinu kódu můžeš přesunout do samostatných třídy komponent a zbudou ti jen pravidla pro přesměrování a předávání dat modelům. Čili ten jeden presenter by až tak velký nebyl. Ale Pokud to rozdělíš na více presenterů tak se vůbec nic nestane :)

dcepelik

Na výše uvedeném příkladu to nemusí být patrné, ale ve skutečné aplikaci jsou „cesty“ mnohem spletitější.

Díky, že jste přibrzdili mé filosofické rozpravy, zkusím to a uvidím.

dcepelik

22 napsal(a):

Nevím, co v tom hledáš za složitost? Všechno obslouží v klidu jeden presenter s více view, maximálně ve spolupráci s nějakou/nějakými komponentami

neregistrovaný je odkopnut na registraci nebo data formuláře se nevyplní, pokud nejsou v session

registrovanému uživateli se data natáhnou z DB. V krokovém formuláři jedno view přeskočíš

Ano, vypadá to jednoduše. Ale situace je trochu jiná.

Abych věděl, zda mám či nemám v krokovém formuláři view přeskočit, musím znát cestu, kterou uživatel jde. Neregistrovaného uživatele nechci „odkopnout na registraci“, chci, aby mohl nakoupit i bez ní.

Přesto díky, zkusím a uvidím.

22

Proč by na tom mělo záležet, odkud uživatel přišel? To se mi zdá opravdu zvláštní..

Filip Procházka

Říká se tomu cílení na uživatele, nebo tak nějak, ne? :)

22

Aha takto, to z toho prvotního popisu příliš nevyplývá.. ale i tak to věc asi nijak moc výrazně nekomplikuje imho nebo ano?

dcepelik

HosipLan napsal(a):

Říká se tomu cílení na uživatele, nebo tak nějak, ne? :)

Ano, z části jde vskutku o cílení na uživatele. Měl jsem uvést konkrétní problém, ne konstruovat nový, bývalo by to bylo zřejmější.

Stavím aplikaci, kterou využije jeden pár (ve smyslu dva lidé). Oba vyplní formulář, avšak jen první z nich za službu zaplatí (platí za oba) a dostane přístupový kód pro druhého uživatele (var. A). Druhý uživatel přijde na web, vyplní formulář, ale už neplatí (protože zadal kód, var. B).

Var. C: přijde nezúčastněná osoba a zaplatí službu za jiný pár (jako dárek, dostane dva kódy). Nechci zabíhat do větších detailů.

Takže jsou tři „cesty“ nebo „způsoby využití“ aplikace, všechny podobné, ale s odlišnostmi (a je sakra podstatný rozdíl, jestli uživatel bude platit, nebo ne).

Nakonec jsem se rozhodl var. A a B sloučit, protože jde o nejpodobnější kombinaci a trochu skrouhnout navržený proces, aby to bylo zvládnutelné. Platbu vyčlením zvlášť a z var. A a B na ni odkážu po vyplnění formuláře, zatímco v případě C na ni odkážu rovnou.

Snad je tomu aspoň trochu rozumět. Teď už jen vymyslet nějaké rozumné názvy a je to.

Editoval dcepelik (18. 9. 2011 11:27)