Rozwiązania problemów z prezentacji na Cooluarach
Podczas mojej prezentacji na Cooluarach pojawiło się kilka małych problemów, których nie potrafiłem rozwiązać lub po prostu nie zdąrzyłem rozwiązać. Poniżej rozwiązania problemów, które zapamiętałem. Jeśli ktoś pamięta jeszcze jakieś inne, lub po prostu ma pytania, to zapraszam do podesłania. Z przyjemnością odpowiem (lub przynajmniej spróbuję).
Poukładana aplikacja z prezentacji dostępna jest na Kenai.
AJAX i g:submitToRemote
Podczas próby użycia AJAXa za pierwszym razem wstawiłem przycisk submitToRemote i nie zadziałało. Następnie spróbowaliśmy z formRemote. Początkowo nie działało. Ostatecznie okazało się, że zabrakło deklaracji użycia odpowiedniej biblioteki JS i formRemote zadziałał. Nie sprawdziliśmy już submitToRemote, ale problem był dokładnie ten sam. Gdybyśmy dołączyli odpowiednią bibliotekę JS to użycie AJAXa zajęłoby nam 2 minuty, a nie 10 
Tag meta do ustawiania layout'u
Jedną z możliwości ustawienia layout'u dla naszego widoku jest tag meta:
<meta name="layout" content="nazwaLayoutu"/>
Pozostaje on jednak w ostatecznie złożonej strukturze strony. Innym sposobem jest taka konstrukcja:
<g:applyLayout name="nazwaLayoutu"> zawartość </g:applyLayout>
Zagnieżdżony własny tag
Podczas prezentacji próbowaliśmy zagnieździć własny tag w tagu each. Nasz tag miał robić uppercase na podanym parametrze. Nie zadziałało. Okazało się, że w tagu each używaliśmy domyślnej nazwy zmiennej z domknięć, czyli "it". W momencie, gdy wstawiliśmy to do naszego nowego tag'a "it" wskazywało na domyślny parametr domknięcia definiującego nasz tag, czyli było to puste i leciał zwykły NPE. Wystarczyło w tagu each dodać atrybut var, który definiuje nazwę zmiennej w bieżącej iteracji i jej użyć w naszym tagu.
Jak obsłużyć błąd wewnątrz flow
Nie udało mi się sprawić, aby automatycznie było generowane zdarzenie error wewnątrz flow'a, jeśli nie uda się zapis do bazy. Jednak prostym kawałkiem kodu udało się wygenerować zdarzenie error, gdy nie uda się walidacja. Przykład w kodzie do pobrania. Wydawało mi się, że próbowaliśmy z taką kombinacją podczas prezentacji. Może była jakaś literówka.
Konfigurowalne wstrzyknięcie zależności
Podczas prezentacji Dawid zadał dość istotne pytanie: jak wstrzyknąć inną implementację usługi, skoro domyślnie jest to realizowane po nazwach (konwencja). Przecież całym urokiem wstrzykiwania zależności jest łatwa możliwość podmiany implementacji.
Okazuje się, że jest to oczywiście proste i możliwe. W końcu pod maską jest Spring. Tak więc możemy bez problemu wstrzyknąć dowolną zależność. Możemy to zrobić przez znany ze Spring'a resources.xml albo Grailsowy resources.groovy. Możemy do niego dolożyć dowolny fragment logiki uzależniający nasze wstrzyknięcia od dowolnych parametrów (np. sprawdzić czy to środowisko testowe lub produkcyjne, albo sprawdzić czy jakiś WebService jest dostępny, a jeśli nie to wstrzyknąć jakąs protezę, itp.). Przykład w referencyjnej aplikacji, a więcej szczegółów w dokumentacji.
Jak odwzorowane są w bazie constrainty nullable i blank
Domyślnie pola generowane są w bazie jako NOT NULL, czyli odpowiednik dopisania w sekcji constraints nullable:false. Nic to nie zmienia. Zmienienie nullable na true wpłynie na wygenerowany schemat. Natomiast constraint blank nie wpływa w żaden sposób na generacje schematu. Jest to walidacja wykonywana tylko we framework'u. Tak jak podczas prezentacji jeden z kolegów zauważył (przepraszam, nie pamiętam imienia) nasze problemy z walidacją wynikały z tego, że wartość przychodząca z formularza była pustym stringiem, a nie null'em. Dlatego też dopiero constraint blank nam pomógł. Oczywiście jest to ładnie w dokumentacji opisane
To tyle z tego co zapamiętałem. Miłego przeglądania, czekam na uwagi, komentarze i dalsze pytania
