![]() |
![]() ![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 348 Pomógł: 26 Dołączył: 8.10.2008 Skąd: Lublin Ostrzeżenie: (0%) ![]() ![]() |
Witajcie.
Jestem w trakcie robienia sklepu internetowego na podstawie innego, gdzie 3 kroki kupowania są napisane strukturalnie, a dokładniej na SWITCHu. W kroku pierwszym jest wybór formy płatności i formy transportu. Jest zaimplementowany system płatności raty żagiel. Krok 2 i 3 i stado IFów przez które rozstrzyga się jaki formularz załadować i jakie ceny wyświetlić względem tego jaki użytkownik wybrał transport i jaką formę transportu. Teraz muszę dodać do tego skryptu inne możliwości płatności, PayPal itd i jest to koszmar, ten skrypt ma się dalej w przyszłości rozwijać dlatego trzeba to przerobić. Próbuje rozrysowywać to, robić schematy i nie moge wymyślić jak to zrobić... co ma być intefrejsem, co klasą abstrakcyjną a co pozostawić w tym SWITCHu z 3 krokami (SWITCH ($_GET['krok']) i wszystko w sesjach... )... Wiem, że problem prosty do rozwiązania ale odpowiedzieć na niego to nie jest minutka jednak dla mnie to pierwsza rzecz obiektowa w której chciałbym w końcu użyć interfejsów bo wiem, że ta część skryptu ma się rozwijać. Nie wiadomo ile będzie form płatności i transportu. Dodam jeszcze że forma płatności może mieć wpływ na cenę (np. za pobraniem) ale admin ma możliwość sam dodawać formy płatności i ewentualnie uploadować plik z dodatkowym formularzem. Pozdrawiam. |
|
|
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 872 Pomógł: 94 Dołączył: 31.03.2010 Ostrzeżenie: (0%) ![]() ![]() |
Niestety nie znamy tego kodu, chcialbym pomoc ale nie mam jak. Wrzuc jakis przyklad, bo stwierdzenie "stado IFów" jest bardzo subiektywne i nie oddaje istoty problemu.
|
|
|
![]()
Post
#3
|
|
Grupa: Zarejestrowani Postów: 348 Pomógł: 26 Dołączył: 8.10.2008 Skąd: Lublin Ostrzeżenie: (0%) ![]() ![]() |
Ponieważ - uważam - stado IF'ów samo w sobie jest problemem, tym bardziej, gdy z tego powodu bardzo problematyczne jest nawet drobne rozszerzenie skryptu.
To o co proszę to koncepcja napisania zespołu klas i interfejsów umożliwiających bezproblemowy przebieg zakupów w 3 krokach: Krok 1: Użytkownik (klient) wybiera formę płatności i formę transportu (+ podaje swoje daje jeśli jest nie zarejestrowany) Krok 2: Jeżeli użytkownik wybrał formę płatności Raty Żagiel to pojawiają się przyciski "Oblicz ratę" i "Zapoznałem się z regulaminem kupowania na raty" + lista produktów wraz z cenami + na tej liście ewentualna cena transportu Krok 3: Zatwierdzenie, jeżeli były wybrane raty to ten krok przenosi do ich systemu, po wypełnieniu formularza w żaglu jest zwrot do kroku czwartego, w innym przypadku kończy się na kroku trzecim. Jak można się domyślić w każdym z kroków (SWITCH ($_GET['krok']) case 1: ... break; case 2: ... break; case 3: ... break; ) jest w cholerę ifów, bo w zależności od tego jaką kombinację użytkownik wybrał w pierwszym kroku to inne rzeczy mają się wydarzyć, wyświetlić. Np. jeżeli użytkownik wybrał dowóz towaru do domu to w drugim kroku jest dołączana funkcja licząca cenę transportu na podstawie wagi towaru + dodatkowa dopłata jeżeli towar jest jakiś specjalny i jego wysyłka wymaga jakichś dodatkowych działań czy zabezpieczeń. I przyszło mi do tego dodać jeszcze kilka systemów płatności gdzie dodanie jednego to jakby to nazwać syzyfowe prace... Jestem pewien, że da się to rozplanować obiektowo żeby miało to ręce i nogi. Dla pokazania wrzucam jednego case'a: (przerabiałem już ten kod ale nie jest mój)
Ten post edytował Adi32 6.09.2012, 13:00:35 |
|
|
![]()
Post
#4
|
|
Grupa: Zarejestrowani Postów: 53 Pomógł: 0 Dołączył: 30.11.2010 Ostrzeżenie: (0%) ![]() ![]() |
Może utwórz sobie do każdego sposobu płatności osobną klasę i funkcję która będzie ją załączała i tworzyła w zależności od tego co user wybierze. Czasami warto trochę więcej popracować by sobie ułatwić życie. Bez sensu twardo tworzyć każdego IFa w każdym case-ie, powiela się kod w ten sposób. Z klasy np class.payu.php będziesz mógł zawsze skorzystać. Warto bazę w to zaangażować skoro piszesz że ma to byś dalej rozwijane.
Nie do końca zrozumiałem pytanie. |
|
|
![]()
Post
#5
|
|
Grupa: Zarejestrowani Postów: 2 885 Pomógł: 463 Dołączył: 3.10.2009 Skąd: Wrocław Ostrzeżenie: (0%) ![]() ![]() |
Takie kwestie są z reguły skomplikowane, ponieważ jest tu pewien proces ciągły, proces zakupowy, w którym mamy do czynienia z wielokrotnym wyborem i z mnóstwem czynników, które wpływają na przebieg tego procesu, m.in.:
- wymieniony rodzaj i sposób wysyłki, z możliwością skalkulowania kosztów i wyborem usługodawcy, dodatkowo tutaj wpływ ma destynacja przesyłki plus opcje dodatkowe, np. masa i wymiary paczki, możliwość ekspresowej wysyłki za dopłatą (termin dostawy) - od strony produktu - wszystko, co wpłynie na masę przesyłki, a więc - głównie rozmiar, ilość produktów etc. - model cenowy produktu uwzględniający możliwe rabaty (nawet kilka jednocześnie w zależności od promocji i tego, na co ostatecznie skusi się klient, jeżeli pod pewnymi warunkami zaoferujemy mu rabat jeśli np. wybierze więcej niż jedną sztukę produktu) - także pozostałe rabaty i promocje okolicznościowe itp. - dostępne metody i sposoby płatności Magento może nie jest mistrzem w tej kwestii, ale jeśli przyjrzymy się wybranym obiektom i relacjom między nimi na pierwszych z brzegu diagramach związków encji, to temat wydaje się bardziej skomplikowany, niż można byłoby przypuszczać: Klient i jego tzw. otoczenie wysyłka Promocje, zniżki, rabaty Koszyk płatności Ciężko sobie wyobrazić próbować oddać te wszystkie relacje za pomocą ifów i switch-case. Najlepiej przyjrzeć się procesom zakupowym w kilku najpopularniejszych platformach e-commerce, wytypować kilka, do trzech, które z nich najbliżej oddają to, co chcemy osiągnąć i dokonać porównania i analizy, wybierając najlepsze rozwiązania. |
|
|
![]()
Post
#6
|
|
Grupa: Zarejestrowani Postów: 348 Pomógł: 26 Dołączył: 8.10.2008 Skąd: Lublin Ostrzeżenie: (0%) ![]() ![]() |
Ciężko sobie wyobrazić próbować oddać te wszystkie relacje za pomocą ifów i switch-case. Ano, ciężko... Jednak rozwiązanie na pewno będzie prostsze niż te z Magneto. Jeśli się da... Mam obowiązek stworzyć sklep w wersji BOX. Większość mam już zrobione i zostało właśnie to kupowanie. Administrator ma mieć możliwość włączania i wyłączania sposobów płatności a programiści mają mieć łatwą możliwość dodawania ich. Zależności pomiędzy poszczególnymi wyborami jest zbyt wiele żebym mógł sobie to jakoś wyobrazić i ubrać w klasy. Na pewno będę kombinował jednak dzisiaj mija termin... Nie pozostaje mi nic tylko zacząć to robić i może samo mi się jakoś rozświetli. Dzięki za odpowiedzi. |
|
|
![]()
Post
#7
|
|
Grupa: Zarejestrowani Postów: 37 Pomógł: 2 Dołączył: 1.07.2009 Ostrzeżenie: (0%) ![]() ![]() |
Jesli chodzi o zaimplementowanie platnosci, to sprawa jest prosta. Wdrozylem ponizsze rozwiazanie i dziala znakomicie.
Temat: System platnosci on line Jaki wzorzec |
|
|
![]()
Post
#8
|
|
Grupa: Zarejestrowani Postów: 348 Pomógł: 26 Dołączył: 8.10.2008 Skąd: Lublin Ostrzeżenie: (0%) ![]() ![]() |
Jesli chodzi o zaimplementowanie platnosci, to sprawa jest prosta. Wdrozylem ponizsze rozwiazanie i dziala znakomicie. Temat: System platnosci on line Jaki wzorzec Jestem 'troszke' dalej. Napisałem już coś w ten deseń, zapakowałem to do sesji, nie wiem czy słuszeni aby na następnych krokach (stronach) móc się odwoływać do pól. Teraz pozostało dorobić dla każdego systemu inny formularz i inne wpływy na cenę, do tego powiązać to jakoś z systemem transportu który mam zamiar zrobić w ten sam sposób. Nie wiem czy będzie to miało ręce i nogi ale na nic innego nie mam czasu a będzie to rozwiązanie lepsze od dotychczasowego. Dzięki i pozdrawiam. |
|
|
![]() ![]() |
![]() |
Aktualny czas: 4.10.2025 - 17:56 |