Czy powinienem korzystać z helperów czy to rzecz uznaniowa? Dodam że wygodniej mi jakoś nie korzystać z nich.
0
2
"Wygodniej nie korzystać" - czyli jakie masz alternatywy? Pakowanie logiki w środek template'ów?
Dobry design kodu widać przede wszystkim o dobrym otestowaniu/ pokryciu kodu testami. Na upartego template'y też są kodem i też można je testować - przez wygenerowanie ich i zapisanie wygenerowanego HTMLa do późniejszego porównania w teście jednostkowym. Pakując logikę do szablonu będzie trudniej go przetestować, bo efektywnie staje się jedną wielką metodą.
Możesz wszystkie dane przygotować przed przekazaniem sterowania do template'a za pomocą osobnej case classy i w templacie tylko użyć akcesorów do pobrania, a następnie wyrenderowania wartości. Ma to (tak mi się teraz wydaje) pewną wadę (w sumie to z punktu widzenia specyfiki języka) - takie tworzenia osobnych case class dla każdej templatki z osobna oznacza więcej kodu niż przesyłanie zbiorów prostych helperów w parametrach.
0
Dobra, może na przykładzie. Jeśli chce zrobić listę typu DropDown to mogę sobie dać <select>, a przesłaną listę w parametrze wyrenderować, mapując liste tak:
o => <option value="@o">@o</option>
Ogólnie zdaje mi się że .map jest nagminnie używane w templatesach, np wygodnie jest przekazać Option[String] i go przemapować na coś tam?
dodanie znacznika <code class="scala"> - furious programming
2
Listę optionów powinieneś renderować w templacie moim zdaniem. W ogóle cały HTML powinien siedzieć wyłącznie w templatach. Helpery służą czemu innemu - zamiast podawać całość gotowych danych jako jeden obiekt to podaje się zbiór helperów, z których każdy ma jakieś tam gettery do generowania danych do wyrenderowania.
Option[String].map(a).getOrElse(b) jest pewnym idiomem (IntelliJ w nowszych wersjach usilnie sugeruje zamianę na Option[String].fold(b)(a) co też z przyjemnością robię :) ) który wiadomo co oznacza i wartości a oraz b są specyficzne dla danej formatki. Czasami zawartość a i b może mocno się różnić - np jeśli Option[String] zawiera jakiś parametr to logika w templatce może wyglądać tak:
val parametr: Option[String]
parametr.map(p => <span>mamy parametr: p</span>).getOrElse(<span>nie podano</span>)
Wypychanie takiej logiki do kontrolera byłoby trochę bez sensu.
1
Ogolnie uzywanie map w takim celu
someOpt.map(v => <h1>v</h1>).getOrElse(<h1>Brak</h1>)
Jest calkowicie bezsensowne.
Zamiast tego lepiej napisac:
<h1>someOpt.getOrElse("Brak")</h1>
W celu unikniecia duplikacji kodu.