dbsupport
commented
7 years ago From @lazydevelopers on July 19, 2014 11:24
Ostatnie ustalenia:
1. będzie zdefiniowana lista "funkcji" w postaci parametrów w sql.
Funkcja definiowana jest przez nazwę parametru, który może pojawić się w czasie przetwarzania raportu. Obsługa funkcji jest określona indywidualnie. Nazwy parametrów oznaczające funkcję zaczynają się od OUT_
2. Powstanie "log" generacji raportu, w którym pojawiać się będą wpisy o przetwarzaniu.
Wpisy logu będą widoczne przy raporcie (na liście, szczegółach itd).
3. nowy atrybut przy raporcie: downloadable: oznacza czy można pobrać treść raportu czy nie.
OUT_TERMINATE = result:[0,1]|msg:treść
Jeśli pojawi się w czasie przetwarzania z wartością result=1 oznacza przerwanie dalszej generacji raportu ze stanem "poprawnym", downloadable=false . W logu powinien pojawić się wpis z przekazanym msg. Jeśli pojawi się z result=0 kontynuuj przetwarzanie.
OUT_COMMENT = result:[0,1]|msg:treść
Jeśli pojawi się z result=1 dokona wpisu msg do logu.
From @dbsupport on July 3, 2014 12:38
Przekazywanie parametrów wyjściowych generacji do aplikacji (wartości zmiennych z selecta w bloku / parametry OUT podobnie jak wejściowe IN/).
Wstępny pomysł na funkcje przerywania: jeśli w definicji ustawię wartośc parametru OUT_FILE np na stałą CANCEL to aplikacja nie wygeneruje pliku. Inna zmienna, np OUT_MESSAGE przekaże treść komunikatu do wyświetlenia w aplikacji.
Copied from original issue: dbsupport/dbs-reports-issues#36