Robię kalendarz. Potrzebuję pobrać dane z bazy po wybraniu danego dnia. Zastanawiam się jak to zrobić. Czy lepiej z serwera otrzymać dane w postaci np.: json i przetworzyć je w javascript, czy stworzyć po stronie serwera gotowy html zawierający dane? A może jakiś inny sposób. Danych nie będzie dużo. po wybraniu dnia mają się pojawić dostępne godziny. Strona też nie będzie miała dużego obciążenia. Działać będzie jedno i drugie rozwiązanie, ale jak już coś robić to robić dobrze.
0
1
Bednarus3 napisał(a):
Działać będzie jedno i drugie rozwiązanie, ale jak już coś robić to robić dobrze.
Jeśli chcesz "robić to robić dobrze", to zbuduj swoją aplikację w taki sposób, żeby nawet nie wiedziała czy dostaje dane z servera w postaci JSON czy HTML - to byłoby na prawdę zrobienie tego dobrze.
Możesz to zrobić w taki sposób, że w momencie w którym klikasz ten przycisk, wołasz polimorficzną funkcję, która wyświetla dane, np displayCalendarItem() .Ty, jak użytkownik tej funkcji, nie wiesz dokładnie jak to działa. Ta funkcja mogłaby dostawać HTML z serwera, albo mogłaby dostać JSON'a i sama wyrenderować HTML. To jest abstrakcja.
Złą decyzją którą mógłbyś podjąć nie jest to czy dostaniesz dane jako HTML czy JSON (bo jak mówiłeś - oba zadziałają), ale właśnie to że ten wybór będzie miał konsekwencje, bo np. aplikacja będzie o tym wiedzieć, a nie powinna. Powinieneś ją napisać tak, żeby zminimalizować te konsekwencje.
0
To chyba jakaś prowokacja jest :) Dziękuję.
0
Bednarus3 napisał(a):
To chyba jakaś prowokacja jest :) Dziękuję.
Żadna prowokacja. Pokaż swój kod to Ci pokażę, jak łatwo można to zrobić.
Pamiętaj, że protokół komunikacyjny klienta z serwerem (czyli np to czy serwer wysyła HTML czy JSON) to jest szczegół implementacyjny, nieistotny z punktu widzenia użytkownika. Owszem, musisz te dane wysłać jakoś, w sposób pozwalający na wyświetlenie tych danych, ale to czy wyślesz gotowy widok w HTML'u, czy dane w JSON, XML czy innym formacie, to nie ma znaczenia - i konsekwencje tej decyzji powinny być zatrzymane w bardzo małej proporcji.
Innymi słowy - jeśli wybierzesz HTML albo JSON do komunikacji, to byłoby to źle zrobione, gdyby potem zmiana tego podejścia wymagała zmiany w połowie aplikacji.
Pytałeś jak to zrobić dobrze, to Ci powiedziałem.
0
Dodając do tego co @Riddle napisał, w tym wypadku nie ma dobrej czy złej odpowiedzi. Jak ja bym miał to zrobić to zadałbym sobie pytania:
- czy jest już jakiś pattern w aplikacji do tego typu sytaucji?
- co jest prostsze w moim stacku technologicznym? Jakbym miał teraz stawiać np. aplikację Ruby on Rails to gdzie się da przesyłałbym HTML, ale jakybm miał isteniejącą appke opartą na JSON api to raczej zostałbym przy JSON
- czy w moim zespole jest wiedza jak to utrzymać?
Od jakiegoś czasu widać ruch w kierunku "HTML over the wire", patrz https://hotwired.dev/, https://htmx.org/examples/click-to-edit/.
3
Ale mieszacie autorowi jakimiś bzdurami bez konkretów.
Oba rozwiązania są stosowane i oba są ok. W zależności od tego z jakiej technologii korzystasz jedno jest popularniejsze a drugie mniej.
Jeśli na Froncie chcesz dużo interakcji i będziesz korzystać z jakiegoś frameworka to ja polecałbym po prostu przesyłać JSONem.
1
Dziękuję. Nie trudnię się na co dzień programowaniem. Firma w której pracuję potrzebuje aplikację służącą do rezerwacji wejścia na obiekt. Tworzę to nie wykorzystując żadnych frameworków. Wykorzystuję do tego HTML+CSS, javascript, PHP, MySQL i kod pisany z palca wspomaganego przez kopiuj - wklej. Mimo iż to nie jest produkt komercyjny i do tego mały, chcę to zrobić zgodnie ze sztuką. Mnie uczono, że aplikacje powinny być jak najbardziej wydajne i bezpieczne. Pod tym kątem zadałem pytanie, a poza ostatnim wpisem dostałem odpowiedzi, że aplikacja ma być tak napisana, żeby zespół programistów mógł się łatwo po niej poruszać w przypadku wprowadzania późniejszych modyfikacji. Wracając do wydajności to doczytałem, że są przypadki, gdzie użycie metody appendChild jest wydajniejsze, a są gdzie zmiana własności innerHTML. Przy tak małej aplikacji jak moja jest to nieistotne. Pozostanę przy zmianie innerHTML.