Witajcie użytkownicy.
Proste pewnie pytanie ale nie mam pomysłu.
Otóż, mam w widoku model(który ma w relacji "jeden do wielu" kilka tabel ) i w formularzy chciałbym poprzez "asp-for" zbindować właśnie te dane do obiekty nadrzędnego.
Jednak gdy odwołam się do @model.nazwatabeli to nie mam już tych propertisów. Niestety zapytanie poprzez. Select wyrzuca błąd, że nie można tego używać. Jakie jest prawidłowe podejście?
Dziękuję i pozdrawiam!
Czy używasz EntityFramework? Jeśli tak, to sprawdź konfigurację Lazy Loadingu i nie zapominaj o Include. Jeszcze lepiej byłoby, gdybyś nie wrzucał na widok obiektów bezpośrednio mapowanych na tabele, a mapował je na inne (zwykle jakieś DTO, VIewModel itp.), odłączając od śledzenia przez ORM i zarazem kłopotów. Wtedy też łatwiej zdebugujesz co idzie na widok.
@SkrzydlatyWąż: tak, korzystam z Entity i również z ViewModeli.
Problem jest u mnie bardziej złożony ponieważ daję możliwość dodania przez użytkownika dodatkowych wierszy inputów.
Wygląda to tak, że mam taki ViewModel
public class ApplicationViewModel
{
public int Id { get; set; }
public double Incomes { get; set; }
public List<ApplicationAssetsViewModel> Assets { get; set; }
//itd.
}
A w widoku generuję wiersze inuputów plus mam skrypt pozwalający klientowi dodanie kolejnych inputów.
I właśnie tu jest problem, że nie bardzo wiem jak się do tego zabrać by później Razor zbindował wszystko do ViewModelu i przesłał do kontrolera...
Jeśli dobrze rozumiem, potrzebujesz wysłać kolekcję z widoku do kontrolera? A próbowałeś w ten sposób? https://stackoverflow.com/a/23553027
@SkrzydlatyWąż
Niestety to nie do końca spełniało to co chciałem uzyskać ale jednak pomogło.
Jak zwykle dwa dni napisane z 300 linii kodu no i wszystko do kosza ale znalazłem dużo krótsze rozwiązanie.
Dla potomnych:
-w widoku razora tworzymy pętle for tworzącą tyle row-ów inputów ile chcemy maksymalnie udostępnić użytkownikowi.
-wszystkim nadajemy atrybut hidden i dopisujemy js skrypt, który po naciśnięciu przycisku dodaj będzie kolejno zdejmował atrybut z kolejnych row-ów.
w widoku nasza logika powinna wyglądać mniej więcej tak:
@for (int index = 0; index <= 3; index++)
{
<textarea asp-for="NaszViewModel[index].Parametr" class="form-control" rows="5" placeholder="Opi"></textarea>
//itd...
}
Po wprowadzeniu przez usera danych wszystko ładnie binduje się do naszego ViewModelu
A czemu najpierw tworzyć hidden inputy, zamiast po prostu dodawać nowy po naciśnięciu przycisku?
@somekind: Nie do końca wiem jak to zrobić w razorze a chciałem użyć helpera 'asp-for'. Gdybym miał tworzyć skrypt po stronie klienta nie wiem czy bindowanie później do kontrolera poszłoby mi tak dobrze.
Ale jak sam widzisz, musiałeś napisać coś w JS, więc nie jesteś w stanie wszystkiego zrobić po stronie serwera.
A, żeby bindowanie działało, wystarczy że input będzie miał atrybut name odpowiadający nazwie właściwości z uwzględnieniem indeksu kolekcji.
@somekind tak to widziałem ale też zauważyłem, że razor dodaje jeszcze atrybuty z grupy "data-val" i wtedy mogę sobie po stronie viewmodel`u ustalać ograniczenia.
A w sumie miałbym do Ciebie dwa pytania, będę wdzięczny jeśli mi poradzisz.
Phoryn napisał(a):
@somekind tak to widziałem ale też zauważyłem, że razor dodaje jeszcze atrybuty z grupy "data-val" i wtedy mogę sobie po stronie viewmodel`u ustalać ograniczenia.
Myślę, że wszystkie te atrybuty można dodać po stronie klienta.
A w sumie miałbym do Ciebie dwa pytania, będę wdzięczny jeśli mi poradzisz.
- Jakie zagrożenia (prócz większej ilości wygenerowanego kodu html) niesie moje podejście vs podejście generowania inputów po stronie klienta?
No ja bym się właśnie tym niepotrzebnie generowanym kodem martwił. Takie dziwne to jest - tworzyć i ukrywać zamiast tworzyć tylko wtedy, gdy potrzebne.
- Robię dosyć rozbudowany formularz, który dobrze gdyby ograniczał klientowi możliwość wpisania do niektórych pól np. tylko integerów lub typu datetime. Na tę chwilę wszystkie inputy są textareami i chcę po prostu ograniczyć użytkownikowi w viewmodelach typ wprowadzonych danych. Czy jest lepsze podejście?
Myślę, że po to są różne rodzaje inputów, żeby ich używać. Razor nie generuje inputów dopastowanych do typów danych z ViewModeli?
@somekind
Rozumiem. No jeśli chodzi tylko o kod generowany po stronie klienta (w sensie o jego ilość czyli jego wydajność) to jakoś to przeboleję. Oby nie dawało to możliwości na jakiś atak.
No właśnie te textarea stosowałem ponieważ chciałem mieć inputy z kilkoma row`ami. Ale to chyba bez sensu jak teraz o tym myślę, zmienię ich wielkosć po prostu w css i pozamieniam to wszystko na inputy.
Powiedz mi tylko jaki jest wzorzecz dla budowania takich dużych formularzy?
robi się to jako table czy form z li?
Dzięki