Autor Zpráva
AdiOverRide
Profil
Zdravím pánové a dámy :),
pracuji na svém eshopovém systému a dostal jsem se do fáze, kdy bych chtěl měnit proces objednání např. při výběru platbou přes platební bránu se to přesměruje na "stránku dané platební brány" a né na dokončení objednávky jako třeba při výběru "dobírky". Rád bych to měl co nejlépe řešené, tak že by si uživatel v administraci vybral platební metodu a u ní nastavil třídu které by to řešila. Jak by jste to řešili vy? Návrhový vzor observer, dělali jste něco podobného? Nějaké zkušenosti, kde můžu narazit třeba s observer?

Díky za každou radu, A.
Enko
Profil
Možná OT, ale podle mě nemá smysl znovu sestavovat kolo a raději používat již hotové řešení. Např Prestashop, který má vše a je jednoduše rozšiřitelný. A hotový eshop se vším máš hotový za pár minut.
mimochodec
Profil
Enko:
To je super, že už někdo vymyslel dokonalý eshop. Zastavme vývoj všech dalších, je to zbytečné.
Alphard
Profil
AdiOverRide [#1]:
Pro observer tady moc nevidím důvod. Vygenerování stránky je otázka zlomku sekundy, neočekáváme, že v té době dojde ke změně nastavení, které se budou propagovat do zbytku aplikace. Nevím, jak složitý je váš systém, ale mělo by stačit úplně jednoduché řešení. Objekt A starající se o průběh objednávky se zeptá objektu B, jakou metodu má použít a objekt B mu ihned odpoví.
Tori
Profil
Zmíněný Prestashop používá v podstatě taky Observer. Každý modul si může libovolnou svou metodu zaregistrovat jako tzv. hook, tj. předá systému callback na ni a řekne, při jaké události se má metoda zavolat. Hooky (události) jsou dvou typů - display* a action*; např. platební moduly se registrují na "displayPayment", callback vrací HTML s další možností platby; action* hooky nic nevracejí, reagují např. na update produktu. Pro hooky je nějaká signatura, kterou musí callback metoda dodržet, ale není nijak vynucená rozhraním a některé hooky mají sig. trochu odlišnou. U Nette by se použily události: $object->onChange[] = callback($this, 'methodName'); // přibližná syntax
Alphard
Profil
Když teď znovu čtu dotaz, zdá se mi, že uživatelem v dotazu není myšlen objednávající, ale admin konkrétní instalace systému. Pak je moje odpověď mimo.
aDAm
Profil
Řek bych že se to řeší docela zbytečně složitě. Proč by měl uživatel definovat nějaké třídy? Po uživateli se přece chce aby toho dělal co nejméně neb jak je známo je to líný tvor a tak mu prostě nabídnou checkboxy/radiobuttony kterými si vybere jaké platební metody chce použít - dobírka, převod, paypal, atd. atd.

Samotná aplikace to pak vyřeší tak že v objednávkovém procesu si kupující vybere jak chce platit. Když vybere třeba dobírku, tak se objednávka vytvoří, vytvoří se podklady pro dobírku a poděkuje se za nákup. Pokud ale vybere paypal či jinou bránu tak se vytvoří objednávka (bez ní snad žádná brána nefunguje) uživateli se "podstrční" form brány aby se na ní přesměroval, na bráně provede platbu a vrátí se zpět na děkující stránku.

Proč tedy řešit nějaké třídy?
Joker
Profil
aDAm:
Proč tedy řešit nějaké třídy?
Tak dejme tomu budu mít pět způsobů výplaty. Dva mají přesměrovat na nějakou URL, dva uložit záznam do databáze a jeden má vygenerovat XML soubor a uložit na disk.

Proč by nemělo být vhodné to implementovat přes třídy?

AdiOverRide:
Jakým způsobem byste chtěl využít observer?
Možná jsem si dotaz představil špatně, ale představil bych si, že objekt pro způsob platby by prostě implementoval nějaké rozhraní (interface) a aplikace by ve chvíli platby zavolala určitou metodu z toho rozhraní.
aDAm
Profil
Joker:
jasně přes třídy jo, ale proč nutit správce aby je nastavoval? Nebylo by vhodnější aby si to odřídila samotná aplikace? To co jsem popsal funguje a platební metody jsou ve formě "pluginu"
AdiOverRide
Profil
Ahoj,
díky za odpovědi, prestashop (to už je mi bližší virtue mart) používat nechci možná je dobrý ale není mi sympatický a nechci řešit a zkoumat jádro jak to funguje a pak na to udělat nějaký složitý modul abych to mohl třeba pronajímat, třeba pomocí nějaké landing page atd.. prostě více rozumím tomu co si napíšu sám.

Nechci po uživatelech aby přímo definovali třídy, ale při vytváření způsobu platby budou mít možnost vybrat rozšíření, které bude spravovat danou platbu (ze selectboxu) při objednávce zákazníkem. Současně řeším jen platební bránu goPay pak možná agmo a řád bych aby to v budoucnu při rozšiřitelnosti dělalo co nejméně problému, takže né všechny platební metody se musí chovat stejně . Tedy si v databázi ukládám názvy rozšíření plus název třídy, která jej zpravuje. Během implementace jsem zjistil že možná observer nebude přímo ideální a tak jsem vytvořil interface a řeším to reflexí (přeci jen vím, kterou třídu chci volat :) ). Určitě co programátor to řešení (názor), byla to tedy spíše teoretický otázka jak by jste to řešili vy.

Díky,
A.
Joker
Profil
aDAm:
jasně přes třídy jo, ale proč nutit správce aby je nastavoval?
Tak pro správce ten seznam tříd může vypadat jako roletka, třeba přidat nový způsob platby a teď budu mít roletku s těmi třídami (třeba: Přesměrování, uložení do databáze, vytvoření XML), jeden vyberu a pak definuji parametry.
aDAm
Profil
Joker:
to už nutíš uživatele přemýšlet a to jak je známo nefunguje ;)
Joker
Profil
aDAm:
Blbuvzdornější postup mě nenapadá. Kromě toho, že by admin způsoby platby nemohl konfigurovat vůbec a dostupné by byly prostě ty, které zadrátoval programátor.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0