Zaawansowane dane wyjściowe - Dokumentace Tritius

* Umożliwiają administratorowi biblioteki tworzenie dowolnych własnych wyników na podstawie danych przechowywanych w bazie danych.

4

* Częścią szablonu jest SQL do bezpośredniego odczytu danych – dane nie są wstępnie przygotowane w Tritiu, jak ma to miejsce w przypadku podstawowych (prostych) wyników.

5

* Szablon jest sparametryzowany, tzn. po wybraniu szablonu przed samym eksportem wyświetla się okno dialogowe z parametrami, które są następnie przekazywane do szablonu.

6

* Zaawansowane wyniki znajdują się w tabeli report_template i mają report_type=ADVANCED.

7

* Przykładowy szablon jest częścią danych wyjściowych Tritia z id = -39.

= Ładowanie danych =

(((

* Częścią szablonu musi być SQL do pobrania danych, które mają być wyświetlane w wynikach.

13

* W iReport wstawia się to w następujący sposób:

14

** Kliknij prawym przyciskiem myszy na nazwę szablonu -> Edytuj zapytanie -> Zapytanie raportu -> Język zapytania: SQL.

15

** W wyświetlonym oknie należy wprowadzić SQL.

16

* Kolumny, które mają być wyświetlane w wynikach (lub z którymi ma być wykonywana jakakolwiek operacja), muszą:

17

** Być wyraźnie wymienione w wykazie kolumn zwracanych przez select.

18

** Posiadać alias (select x AS yz).

19

** Być wymienione w wykazie pól (field) szablonu z odpowiednim typem danych.

20

21

* Przykład zapisu w XML:

|(((

)))

* (((

{{{

<![CDATA[

SELECT [id] AS work_type_id,

34

[name] AS work_type_name

FROM [work_type]

]]>

</queryString>

<field name="work_type_name" class="java.lang.String"/>}}}

)))

)))

* Dostęp do tak zdefiniowanych pól można uzyskać poprzez standardowy zapis $F{název_pole}

46

** pr. $F{work_type_name}

47

48

== Więcej selektów w jednym szablonie bez użycia podraportu ==

49

50

* Należy utworzyć subDataset, który można następnie wywołać w komponencie chart, crosstab, table lub list.

51

* W tej komponencie należy użyć datasetRun, który przekazuje parametry wejściowe do subDataset, zawierającego sam SQL.

52

* SubDataset może mieć parametr, pole, zmienną i grupę, podobnie jak sam raport. Każdy subDataset ma własne zapytanie, a raport może mieć nieograniczoną liczbę subDataset.

53

* jr:listContents jest analogiczny do elementu detail band, można więc umieścić w nim inne elementy.

54

* DatasetRun jest w rzeczywistości podobny do elementu subreport. Może zawierać dataSourceExpression lub connectionExpression, które zmieniają źródło pochodzenia danych.

55

* Ten sam subDataset może być użyty dla wielu datasetRun, dzięki czemu można łatwo użyć tego samego zapytania z różnymi parametrami.

56

57

Przykład zastosowania na liście:

|

{{{ <subDataset name="dataset1" uuid="9fbfd1be-cb5a-476e-940a-afd2e2eb9b1e">

62

63

64

<![CDATA[SELECT work FROM item WHERE id=$P!{parametr1}]]>

</queryString>

</subDataset>}}}

|

{{{ <componentElement>

73

74

<jr:list xmlns:jr="http://jasperreports.sourceforge.net/jasperreports/components" xsi:schemaLocation="http://jasperreports.sourceforge.net/jasperreports/components http://jasperreports.sourceforge.net/xsd/components.xsd" printOrder="Vertical">

</datasetParameter>

</datasetRun>

<jr:listContents height="50" width="553">

</textElement>

</textField>

</jr:listContents>

</jr:list>

</componentElement>}}}

91

92

* W rezultacie pole tekstowe w arkuszu wyświetla identyfikator pracy zapisany w polu pracy dla identyfikatora elementu przesłanego przez subDataset za pomocą parametru „parametr1”, który zapisał wartość w polu pracy.

93

94

Przekazanie wartości ze zmiennej subDataset do głównego raportu można wykonać, dodając:

|

{{{<returnValue fromVariable="promenna_subdataset" toVariable="promenna_reportu"/>}}}

99

100

* Aby parametr/zmienna subDataset miały takie same wartości jak parametr/zmienna głównego raportu, można wykonać następujące czynności:

101

102

[[image:1722591788345-379.PNG||height="284" width="609"]]

103

104

= Parametry wyjściowe =

105

106

* Wyniki mogą być parametryzowane, tzn. czytelnik może ograniczyć dane, które mają być ładowane.

107

* Na przykład ładowanie wypożyczeń konkretnego czytelnika w danym okresie.

108

* Parametry te należy zdefiniować w szablonie

109

* Dodanie parametru w iReport:

110

** Kliknij prawym przyciskiem myszy Parameters -> Add Parameter

111

** Nadaj parametrowi odpowiednią nazwę i ustaw jego typ danych

112

113

== Definicja w szablonie ==

114

115

* Parametr można następnie używać w szablonie, wpisując $P{nazwa_parametru}

116

* Parametr można używać bezpośrednio w SQL do ładowania danych.(((

117

|

118

119

{{{<parameter name="l1" class="java.lang.Long"/>

120

121

<![CDATA[

122

SELECT [name] AS work_type_name

FROM [work_type]

WHERE [id] = $P{l1}

]]>

</queryString>

<field name="work_type_name" class="java.lang.String"/>}}}

)))

* W ten sposób można jednak wstawić parametr tylko bez żadnych dodatkowych modyfikacji.

132

** Działa dla ciągów znaków, liczb.

133

** Nie działa dla daty i zaawansowanych struktur Tritia.

134

* Jeśli parametr wymaga jakiejś obróbki, nie jest to możliwe w części z SQL (ograniczenie JasperReports).

135

* Konieczne jest utworzenie nowego parametru, ustawienie dla niego żądanej wartości, a dopiero potem użycie go w szablonie.

136

* Do tak utworzonego parametru należy uzyskać dostęp poprzez $P!{nazwa_parametru} (dodatkowy wykrzyknik).

137

* Do utworzenia wartości parametru można użyć składania wartości, tak jak w Javie.

* Przykład:

(((

|

* (((

{{{<parameter name="d1" class="java.util.Date"/>

146

147

<defaultValueExpression><![CDATA["[work_type].[date_created] > '" + new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format($P{d1}) + "'"]]></defaultValueExpression>

</parameter>

<![CDATA[

SELECT [name] AS work_type_name

152

FROM [work_type]

153

WHERE $P!{d1_sql_condition}

154

]]>

155

</queryString>

156

<field name="work_type_name" class="java.lang.String"/>}}}

)))

)))

* Dla daty 1.2.2015 10:00:00 w parametrze d1_sql_condition zostanie ustawiona wartość „[work_type].[date_created] > »2015-02-01 10:00:00« ”, co odpowiada zapisowi SQL

163

164

== Parametry obowiązkowe i nieobowiązkowe ==

165

166

* Jeśli parametr jest obowiązkowy, nie ma potrzeby go obsługiwać.

167

* Parametr nieobowiązkowy może pojawić się w szablonie jako NULL – należy zapewnić utworzenie prawidłowego kodu SQL.

168

* W tym celu stosuje się wstępne przetwarzanie parametru, patrz wyżej.

169

* Wykorzystanie operatora trójargumentowego

170

** Jeśli parametr różni się od null, użyj wartości A, w przeciwnym razie użyj wartości B.

171

* Warunek 1=1 – nie ogranicza wyników.

* Przykład:

(((

|

* (((

{{{<parameter name="d1" class="java.util.Date"/>

179

180

<defaultValueExpression><![CDATA[$P{d1} == null ? "1=1" : ("[work].[date_created] > '" + new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format($P{d1}) + "'"]]></defaultValueExpression>

</parameter>

<![CDATA[

SELECT [name] AS work_type_name

185

FROM [work_type]

186

WHERE $P!{d1_sql_condition}

187

]]>

188

</queryString>

189

<field name="work_type_name" class="java.lang.String"/>}}}

)))

)))

* Jeśli parametr ma wartość NULL, stosuje się warunek 1=1 (pobierane są wszystkie rekordy). W przeciwnym razie stosuje się standardowy warunek SQL dla podanej wartości.

196

197

== Definicja w GUI ==

198

199

*

200

** Powyższe rozwiązuje kwestię przetwarzania parametrów pochodzących z Tritia w szablonie.

201

** Konieczne jest jednak zdefiniowanie, że wprowadzenie tych parametrów ma być oferowane w Tritiu.

202

** Zdefiniowane w report_template w kolumnie param2.

203

** Każdy parametr jest określony:

204

** unikalną nazwą – pod tą nazwą jest następnie przetwarzany w szablonie, musi być taka sama, typem danych – aby w Tritiu wyświetlał się odpowiedni komponent do wprowadzenia danych, kluczem do tłumaczenia opisu, określeniem, czy parametr jest opcjonalny.

**Typy danych**

*

** ciąg znaków - s

** wartość całkowita - n

211

** wartość dziesiętna - double

212

** data wraz z godziną - d

213

** data początku dnia (bez składowej czasowej) - ds

214

** data końca dnia (bez składowej czasowej) - de

215

** wartość logiczna - b

216

** użytkownik - u

217

** biblioteka - l

218

** definicja internetowa - w

219

** obiekty bazy danych - wprowadza się jako nazwę klasy UJO (np. Work, Item, ...)

220

*** wyświetlane są w polu kombi

221

222

* **Unikalna nazwa** - składa się z typu danych uzupełnionego o numer

223

** np. d1, u2, Work3

224

225

* **Klucz do tłumaczenia** - wyświetlany jako opis wejścia

226

** wprowadzany w nawiasach kwadratowych

227

** np. [User], [Work_id]

228

229

* **Ustawienia obowiązkowe**

230

** Parametry obowiązkowe należy wypełnić w Tritiu, bez nich nie można utworzyć wyjścia.

231

** Parametry są domyślnie obowiązkowe.

232

** Można ustawić opcjonalność, dodając znak ? (znak zapytania) przed nazwą parametru.

233

234

* **Przykłady parametrów**:

235

** n1[Work_id] – obowiązkowy parametr całkowitoliczbowy o nazwie n1 w szablonie i tłumaczeniu Work_id w Tritiu.

236

** ?w2[Web_definition] – parametr nieobowiązkowy, wyświetla się lista rozwijana z definicjami stron internetowych, nazwa w szablonie to w2, a opis w Tritiu to tłumaczenie Web_definition.

237

** Work3[My_work] – parametr obowiązkowy, oferowany jako lista rozwijana z częściami, w szablonie pod nazwą Work3, opis to tłumaczenie My_work.

238

** Każdy szablon może zawierać więcej parametrów – oddzielonych od siebie przecinkiem lub średnikiem.

239

240

* Przykład:

241

** n1[Work_id],?w2[Web_definition] – szablon z 1 parametrem obowiązkowym i jednym opcjonalnym.

242

243

= Rozdzielczość dla różnych baz danych =

244

245

* Różne bazy danych używają różnych metod escapowania tabel.

246

** Mysql - `work`

247

** MSSQL - [work]

248

* Jeśli tworzony jest szablon dla jednej konkretnej bazy danych, nie ma potrzeby zajmowania się tą kwestią.

249

* W szablonie dla wielu baz danych konieczne jest rozwiązanie kwestii escapowania – nie są one ze sobą kompatybilne.

250

* W tym celu stosuje się specjalne tagi parami.

251

** SQL umieszcza się wewnątrz tych tagów.

252

** Escapowanie dostosowuje się do używanej bazy danych.

253

** Konieczne jest escapowanie dla MSSQL.

== <sql> ==

* Używany w części z głównym szablonem SQL.

258

* Nie można go używać w parametrach.

259

* W przypadku SQL należy stosować escapowanie MSSQL.

260

* Należy go umieścić w części ![CDATA[....]] – nie jest to standardowy tag XML, JasperReports nie byłby w stanie go przetworzyć.

* Przykład:

(((

|

{{{<queryString language="SQL">

267

<![CDATA[

268

<sql>

269

SELECT [name] AS work_type_name

FROM [work_type]

</sql>

]]>

</queryString>}}}

)))

== <sqlp> ==

* Używany w części z parametrami.

281

* Nie można go używać w głównym szablonie SQL.

282

* SQL musi mieć escapowanie MSSQL.

283

* Należy go wstawiać do ![CDATA[....]]

* Przykład:

(((

|

{{{<parameter name="d1_sql_condition" class="java.lang.String">

290

<defaultValueExpression><![CDATA[<sqlp>$P{d1} == null ? "1=1" : ("[work].[date_created] > '" + new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format($P{d1}) + "'")</sqlp>]]></defaultValueExpression>

</parameter>}}}

)))

== Różne SQL dla baz danych ==

297

298

* W przypadku bardziej złożonych zapytań SQL sama zmiana escapowania nie wystarczy, ponieważ każda baza danych używa innej składni poleceń.