Hej, nie do końca wiem czy odpowiedni dział bo case z granicy PHP/SQL/FrontEnd :)
Mam relację, że dany formularz może mieć przypisane do siebie wiele produktów czyli są tabele: form, product i form_product_pivot (kiedyś to bedzie meny-to-meny)
Na froncie mam normalnego multiselecta gdzie przy formularzach wybieram jakie ma mieć przypisane produkty... I sedno sprawy... jestem frontem, backend robi znajomy i każe mi wysyłać na backend tablicę z tymi produktami, gdzie ma być dodatkowo znaczenie add albo delete w zależności czy dodałem nowy produkt czy usunąłem, po to, aby potem on wiedział który rekord z tabeli pivot usunąć a który dodać. Jak na mój gust i wiedze, to takie coś jest od czapy, to powinno być ogarnięte w kontrolerze na backendzie a w ogóle to chyba powinien ogarnąć sam z siebie ORM? Backend stoi na symfony api-platform z doctrine z tego co wiem. Nawet jak ORM sam tego nie ogarnie, to jak powinna być zaktualizowana tabla pivot, czy usunięcie wszystkich rekordów z danym form_id i na nowo dodanie przesłanych produktów to ok podejście?
Z tego co piszesz to wszystko robicie źle.
Na początek... Gdzie jest dokumentacja funkcji, które ofertuje back-end?
Nie ma? Czyżby było tak, że wspólnie na żywo projektujecie Back-end i front end i na siłę wymyślacie funkcje back-endowe żeby szybciej zrobić front?
Jeśli tak to jest to jeszcze większa porażka.
Zacznijcie od dokumentacji backend a Ty jak chcesz pomocy to wrzuć ERD z tych tabel, które macie.
Tak "na żywo", trzeba zrobić nową niewielką funkcjonalność to nie projektujemy i nie piszemy dokumentacji, tylko backend dorabia swoje, ja swoje i komunikujemy się ze sobą. Dokumentacją jest potem opisany kod. Case, to z tego co już wyczytałem, typowa funkcja sync() z Laravela, której w symfony nie ma. I tak, takie funkcje jak widać trzeba wymyśleć i ogarnąć po stronie backedu aby uprościć front-end, bo takie rzeczy nie powinny być na froncie.
GreenGo napisał(a):
Tak "na żywo", trzeba zrobić nową niewielką funkcjonalność to nie projektujemy i nie piszemy dokumentacji, tylko backend dorabia swoje, ja swoje i komunikujemy się ze sobą. Dokumentacją jest potem opisany kod.
No sugeruję opisać problem "potem"... Jak będzie już dokumentacja do back-end.
... albo zabrać się za to jak należy. Czyli najpierw zrobić dokumentację.
... albo zrób jak kolega każe i zacznij wysyłać na backend tablicę z tymi produktami, gdzie ma być dodatkowo znaczenie add albo delete cokolwiek by to oznaczało.
nie wiem dokładnie o chodzi z tym oznaczeniem add i delete ale czy nie możesz po prostu z front'u wysłać tablicy z id produktów które dodajesz?
Możesz przecież zrobić też autouzuplnienie selecta i wtedy zawsze przesyłasz pełną tablicę id produktów które są przypisane a na backend zastępuje wszystkie przypisane do danego form. Jeśli chce wiedzieć które usuwa a które dodaje można łatwo porównać dane które aktualnie są w bazie z tymi z front'u.
Jeśli się nie mylę to wiele wymyślania nie ma.
Ps. Nawiązując do tytułu i wspomnianego sync() w lara, sync() nie działa dla relacji one-to-many
Może zacznijmy od tego w jaki sposób komunikujesz się z api, a bardziej jak wygląda struktura endpointu w który uderzasz? Jak apiplatform to zapewne rest API, pewnie wysyłasz post na form z tablicą id produktów? Bądź może wysyłasz tablice kodów IRI, o ile macie włączone to na apiplatform? Nie rozumiem za bardzo w czym tu może być problem?
Rulon napisał(a):
Może zacznijmy od tego w jaki sposób komunikujesz się z api, a bardziej jak wygląda struktura endpointu w który uderzasz?
Nie wie bo ona tworzy się "dynamicznie" podczas Tworzenia fornt-endu. Dlatego kombinują jak konie pod górę zamiast zaimplementować normalnego CRUD'a oraz listę z filtrami. Nie przemyśleli co chcą osiągną i wyszło, że z frontu muszą latać całe listy produktów z flagami co dodano z co skasowano czyli zwykłe WTF!
Innowacyjne podeście, w którym back-end powstaje z wykorzystaniem techniki "HTML Driven Design" :-)
Jak dużo może być tych produktów jednorazowo?
Najprościej to będzie jak za każdym razem wyślesz to co było wybrane w multiselect, a po stronie backendu niech usunie z bazy to wszytko czego nie ma w requescie i doda relację dla tych obiektów, jakich w bazie jeszcze nie ma a zostały przesłane. Nie ma w tym żadnej magii ani nie jest za bardzo skomplikowane.
Jeśli ta lista może mieć ogromne rozmiary to może nie będzie to najrozsądniejszy wybór, ale wiedząc że produkty są wybierane multiselectem zakładam że nie będzie ich sporo.
@michalos25 - z tym add/delete chodziło o oznaczenie, które produkty przy UPDATE mają być usuwane a które dodane, tak aby na backendzie od razu wiedział, które dokładnie rekordy w jaki sposób zmieniać ( dany usunąć czy wstawić). Problem głównie polegał właśnie na tym, że backend ode mnie chciał to oznaczenie add/delete, a ja uważałem, że takie coś nie powinno być rozkminiane po stronie frontu tylko właśnie porównywane na backendzie. Skończyło się tak jak napisał @var wysyłam standardową listę z produktami, a na backendzie powstał skrypcik, który odpowiednio aktualizuję relację :)
Dzięki za pomoc i fajnie, że niektórym się udało napisać coś sensem, nie potrzebując do tego dokumentacji backendu i ERD :)