![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 220 Pomógł: 0 Dołączył: 24.08.2009 Ostrzeżenie: (0%) ![]() ![]() |
Co zrobić, jeśli produktów jest w bazie kilka tysięcy. Wybieranie ich z rozwijanej listy jest bardzo niewygodne. Jak przy pomocy php i mysql to zrobić. Chodzi mi o sposób w jaki najwygodniej sobie zmniejszyć tą listę, ale żeby jednocześnie w miarę wygonie dało się z tego korzystać?
pozdro |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 2 885 Pomógł: 463 Dołączył: 3.10.2009 Skąd: Wrocław Ostrzeżenie: (0%) ![]() ![]() |
Ad 1)
Jeśli rozmawiamy o panelu administracyjnym właściciela sklepu, to moim skromnym zdaniem dobrze zaprojektowane zarządzanie produktem to przede wszystkim: - odpowiedź na pytanie co znaczy wygodne zarządzanie produktami - kod, który jest "dobrze zarządzalny" (klasy) - co jeśli po jakimś czasie okaże się, że trzeba dokonać zmian? będziesz szukał w kodzie-spagetti i zmieniał w stu miejscach dwie linie kodu? - czytelność prezentowanych userowi danych i zachowanie jednolitej logiki i konsekwencji w działaniu - łatwość wprowadzania modyfikacji i dokonywania podstawowych zadań (pełna edycja) - możliwość przerwania edycji produktu bez utraty wprowadzonych zmian i możliwość powrotu do edycji w późniejszym czasie - opcjonalność rozumiana w sposób: jeśli czegoś na razie nie chcę dodawać do produktu, to mogę pominąć ten etap edycji i przejść do następnego tak, aby produkt został dodany do systemu - intuicyjność interfejsu użytkownika (wszystko musi być na swoim miejscu, dokładnie tam, gdzie użytkownik się tego spodziewa) - dbałość o użytkownika: najprościej zapomnieć na chwilę o programowaniu i postawić się na miejscu użytkownika-kompletnego-laika, który nie zna systemu, albo poprosić kolegę o dokonanie oceny, generalnie powinieneś dążyć do tego, aby user nie musiał kilkanaście razy klikać w różne linki, a system nie prosił pięć razy o podanie tych samych danych Podsumowując dodam, że trzeba dążyć do tego, żeby było jak najprościej, a jednocześnie trzeba zachować wysoką elastyczność i dostarczyć dużo możliwości - to zawsze jest pole kompromisu. Jeśli uda się pogodzić te aspekty - można wtedy mówić o dobrym projekcie. Polecam autentycznie usiąść przed kartką papieru i rozpisać sobie cykl logiczny pełnej edycji produktu. Później się tego trzymać w kodzie. Polecam klasy, najpierw projekt interfejsu, potem implementowanie pod interfejs, nigdy odwrotnie (tzn. projektowanie interfejsu pod gotową implementację) - wartością dodaną będzie utworzone w ten sposób kompletne i elastyczne API dostępne np. dla innych programistów. Konkretny przykład: Można zaprezentować listę produktów w postaci tabeli, wyciągasz z bazy pierwszych 20 rekordów, na liście umieszczasz przykładowo: | Numer | Nazwa produktu | Producent | Podgląd | Cena | (cokolwiek jeszcze) | 1. Testowy produkt 1 Testowa corp. <tutaj miniaturka zdjęcia> 1000 zł (cokolwiek jeszcze) 2. Testowy produkt 2 Testowa2 corp. <tutaj miniaturka zdjęcia> 2000 zł (cokolwiek jeszcze) (...) 20. Testowy produkt 20 Testowa20 corp. <tutaj miniaturka zdjęcia> 2000 zł (cokolwiek jeszcze) Jeśli natomiast masz na myśli po prostu widok Klienta sklepu, to nie potrzebujesz edycji, a paginacji i sortowania wyników. Ad 2) Oczywiście, że funkcjami da się obsłużyć PDO, ale czy nie lepiej byłoby mieć wszystkie funkcje obsługi PDO w jednej klasie np. SQL (IMG:style_emoticons/default/questionmark.gif) ? Przy większym projekcie ostatecznie i tak przeprosisz się z programowaniem obiektowym. |
|
|
![]() ![]() |
![]() |
Aktualny czas: 17.10.2025 - 00:52 |