Skocz do zawartości
zwora

Właściwa liczba kombinacji

Rekomendowane odpowiedzi

Witam,

 

Piszę sobie moduł do sprzedaży rolet i żaluzji na wymiar i muszę temat ogarnąć tzw. sposobem. Prestashop niestety nie jest przystosowany do tego typu produktów, bo cena wyliczana jest na podstawie z góry ustalonej kombinacji atrybutów (do tabeli związanej z koszykiem trafia id kombinacji). Chcąc mieć produkty ze zmieniającymi się wymiarami co 1mm plus inne atrybuty musiałbym mieć wieleset milionów kombinacji. Zatem mogę to załatwić na dwa sposoby: tworzyć kombinację dopiero w momencie dodania produktu do koszyka lub podzielić szerokość i wysokość na przedziały o tej samej cenie (np. 50-60cm liczone tak jak 60cm, 60-70cm tak jak 70cm itd, a właściwe wymiary przesyłać jako cechy podane przez użytkownika). Pierwszy sposób ma tę wadę, że liczba kombinacji będzie suskcesywnie rosła. Co prawda mógłbym w module usuwać kombinacje starsze niż ileśtam, ale wtedy użytkownicy stracą historię zakupów. W tym drugim przypadku wychodzi mi liczba kombinacji nawet 5,5tys. dla jednego produktu (ewentualnie mogę ją zmniejszyć tworząc osobne produkty w zależności np. od koloru profila lub grupy tkaniny, ale wolałbym nie musieć tego robić). I mam w związku z tym pytanie. Jaka jest mniej więcej maksymalna liczba atrybutów, przy której sklep działa jeszcze normalnie (nie jest drastycznie obciążony)?

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

 

 

mógłbym w module usuwać kombinacje starsze niż ileśtam, ale wtedy użytkownicy stracą historię zakupów

 

Nie stracą gdyż w chwili tworzenia zamówienia dane zapisywane są do osobnej tabeli i usunięcie produktów czy kombinacji nie powoduje utratę tych danych ale tak nie polecam tej metody.

 

Lepiej chyba tworzyć kombinację w chwili dodania do koszyka produktu i kasować po jakimś czasie.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Dzięki za odpowiedzi. Bawiłem się przed chwilą trochę tym AWP, ale wygląda na to, że nie ma tam możliwości uzależnienia ceny od wartości wpisanej do pola typu text, a mi to jest niezbędne. No chyba, że bym sobie później wprowadził jakieś modyfikacje (ale pewnie licencja tego zabrania), albo zrobił nowy moduł, który by współpracował z AWP. Chętnie kupiłbym ten moduł, gdyby rozwiązywał mój problem, ale wygląda na to, że tak nie jest. Jeśl ijest inaczej to proszę o sprostowanie.

 

Rolety i żaluzje są specyficzne, ponieważ każdy produkt wycenia się trochę inaczej i do każdego produktu musiałby być osobny moduł.

Kiedyś zrobiłem sobie moduł, który liczy cenę od m2 i właśnie dodaje kombinacje w trakcie dodania do koszyka. Ale nie dokończyłem tamtego tematu i teraz do niego wracam. Jednak chciałbym już wyceniać w sposób prawidłowy. W zasadzie to typowo jest tabela szerokość x wysokość ze skokiem co 10cm w jakimś tam zakresie. I to musiałbym wprowadzić albo poprzez odpowiednią funkcjonalność w backoffice (wtedy ceny mógłby zmieniać zwykły użytkownik (nie znający się na programowaniu)), ale prościej zmieniać ceny bezpośrednio w bazie danych lub jeszcze lepiej zaszyć ceny w zapytaniu sql wysyłanym podczas instalacji modułu. A później na podstawie szerokości i wysokości znalazłbym cenę w tabeli i utworzył kombinację z wpisanych wartości i obliczonej ceny. Równolegle z wysłaniem produktu do koszyka uruchamiałoby się zapytanie sql usuwające kombinacje starsze niż jakiś tam okres. No nic, będę próbował to rozgryźć. Pewnie będę miał jakieś pytania niebawem.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Jeśli planujesz mieć więcej niż kilkadziesiąt produktów i więcej atrybutów niż tylko wysokość i szerokość to tworzenie kombinacji ze wszystkich możliwych wymiarów zajedzie bazę a o FO w którym ceny są wyliczane przez JS nawet nie wspomnę.

 

Tak się składa że mam do napisania podobny moduł i też się nad tym zastanawiam :) Jedyne co mi przychodzi do głowy to tworzenie nowej kombinacji w chwili dodawania produktu do koszyka i usuwanie "tymczasowych" kombinacji po jakimś czasie.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Jeśli planujesz mieć więcej niż kilkadziesiąt produktów i więcej atrybutów niż tylko wysokość i szerokość to tworzenie kombinacji ze wszystkich możliwych wymiarów zajedzie bazę a o FO w którym ceny są wyliczane przez JS nawet nie wspomnę.

 

Tak się składa że mam do napisania podobny moduł i też się nad tym zastanawiam :) Jedyne co mi przychodzi do głowy to tworzenie nowej kombinacji w chwili dodawania produktu do koszyka i usuwanie "tymczasowych" kombinacji po jakimś czasie.

A zacząłeś już coś pisać? I jak chcesz generować cenę? Od m2 czy w inny sposób?

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

To ja coś takiego już mam. Choć nie jest to doskonały moduł (np. trzeba by było przemodelować trochę koszyk). W zasadzie jak sobie tak myślę, to może jednak pozostałbym przy obliczaniu ceny z m2, ale musiłbym wymyślić jakiś bardziej skomplikowany wzór do obliczania nazwijmy to powierzchni zastępczej. Zwykle szerokość ma większy wpływ na cenę niż wysokość. Robienie tabel z cenami dla osobnych produktów i szukanie w nich to mnóstwo pracy.

 

Może razem skonstruujemy coś ciekawego na zasadzie rozwoju tego co mam. Ja tego potrzebuję w zasadzie na użytek prywatny w swoich przyszłych sklepach z roletami, więc nie byłoby tu konfliktu intresów.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Mam jeszcze następujące problemy:

 

1) Po dodaniu do koszyka zmienia się cena produktu, która jest widoczna m.in. w widoku kategorii, przy porównywaniu produktów itp. W jaki sposób mogę wyłączyć  cenę wyświetlaną w tym widoku, albo zastąpić ją stałym wpisem w stylu: już od 10zł? Czy po prostu mam pogrzebać w pliku product-list.tpl?

 

2) Potrzebuję zmienić layout dla produktów na wymiar, bo musze dodać swój formularz, który niezbyt pasuje do oryginalnego layoutu. Chcę sobie podzielić stronę na dwie kolumny, a nie na trzy. Natomiast dla standardowych produktów chciałbym zachować stary layout. Czy da się mieć dwa różne layouty w product.tpl dla różnych rodzajów produktów?

 

3) Zainstalowałem sobie swój moduł w prestashop 1.6 i nie wyświetla mi tabelki w backoffice (w 1.5 działało).

 

W głównym pliku instalującym moduł mam funkcję: "public function hookdisplayBackOfficeHeader($params)", która pobiera z bazy wartości cen i przesyła do pliku z formatką: return $this->display(__FILE__,'plik_z_formatka.tpl');

 

W pliku z formatką mam:

 

<script type="text/javascript">
    $(document).ready(function(){
        $("#product_form #product-tab-content-Informations table:eq(0) tr:eq(0)").after(""

 

i dalej to co chcę wprowadzić. W 1.5 to działało dobrze, a teraz nie. Pewnie się pozmieniały nazwy jakichś elementów, ale nie wiem których. Co muszę zrobić, aby mi to zadziałało w 1.6?

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Jeśli chcesz dodać odpowiedź, zaloguj się

Komentowanie zawartości tej strony możliwe jest po zalogowaniu



Zaloguj się



  • Przeglądający

    Brak zarejestrowanych użytkowników, przeglądających tę stronę.

  • Aktywni użytkownicy

    Nikt jeszcze nie otrzymał reputacji w tym tygodniu.

  • Statystyki forum

    • Tematów
      7 778
    • Postów
      37 069
×