Kod źródłowy Wiki Pokročilé výstupy

Ostatnio modyfikowane 2025/11/21 12:27 przez Jan Slezák

version	line-number	content
1.1	1
	2
2.1	3	* 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.
1.1	8
2.1	9	= Ładowanie danych =
1.1	10
2.1	11	(((
	12	* 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.
1.1	20
2.1	21	* Przykład zapisu w XML:
	22
	23
	24
	25	\|(((
1.1	26
2.1	27	)))
	28
1.1	29	* (((
2.1	30	{{{
	31	<queryString language="SQL">
1.1	32	<![CDATA[
	33	SELECT [id] AS work_type_id,
	34	[name] AS work_type_name
	35	FROM [work_type]
	36	]]>
	37	</queryString>
	38	<field name="work_type_id" class="java.lang.Long"/>
	39	<field name="work_type_name" class="java.lang.String"/>}}}
2.1	40	)))
1.1	41
	42
	43	)))
	44
2.1	45	* Dostęp do tak zdefiniowanych pól można uzyskać poprzez standardowy zapis $F{název_pole}
	46	** pr. $F{work_type_name}
1.1	47
2.1	48	== Więcej selektów w jednym szablonie bez użycia podraportu ==
1.1	49
2.1	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.
1.1	56
2.1	57	Przykład zastosowania na liście:
1.1	58
2.1	59	\|
	60
1.1	61	{{{ <subDataset name="dataset1" uuid="9fbfd1be-cb5a-476e-940a-afd2e2eb9b1e">
	62	<parameter name="parametr1" class="java.lang.String"/>
	63	<queryString>
	64	<![CDATA[SELECT work FROM item WHERE id=$P!{parametr1}]]>
	65	</queryString>
	66	<field name="work" class="java.lang.String"/>
	67	</subDataset>}}}
	68
	69
2.1	70	\|
1.1	71
	72	{{{ <componentElement>
	73	<reportElement x="1" y="76" width="553" height="50" uuid="2968c67b-f548-4c8a-bef3-0df29219b17e"/>
	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">
	75	<datasetRun subDataset="dataset1" uuid="abd17d55-84c6-4e37-9426-cb9f5f59c1a6">
	76	<datasetParameter name="parametr1">
	77	<datasetParameterExpression><![CDATA["66407"]]></datasetParameterExpression>
	78	</datasetParameter>
	79	</datasetRun>
	80	<jr:listContents height="50" width="553">
	81	<textField>
	82	<reportElement x="167" y="16" width="219" height="20" uuid="79972cb3-82ff-4ae5-be0a-89250b9243b5"/>
	83	<textElement verticalAlignment="Middle">
	84	<font fontName="DejaVu Sans" size="11"/>
	85	</textElement>
	86	<textFieldExpression><![CDATA[$F{work}]]></textFieldExpression>
	87	</textField>
	88	</jr:listContents>
	89	</jr:list>
	90	</componentElement>}}}
	91
2.1	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.
1.1	93
2.1	94	Przekazanie wartości ze zmiennej subDataset do głównego raportu można wykonać, dodając:
1.1	95
2.1	96	\|
1.1	97
	98	{{{<returnValue fromVariable="promenna_subdataset" toVariable="promenna_reportu"/>}}}
	99
2.1	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:
1.1	101
	102	[[image:1722591788345-379.PNG\|\|height="284" width="609"]]
	103
2.1	104	= Parametry wyjściowe =
1.1	105
2.1	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
1.1	112
2.1	113	== Definicja w szablonie ==
1.1	114
2.1	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	\|
1.1	118
	119	{{{<parameter name="l1" class="java.lang.Long"/>
	120	<queryString language="SQL">
	121	<![CDATA[
	122	SELECT [name] AS work_type_name
	123	FROM [work_type]
	124	WHERE [id] = $P{l1}
	125	]]>
	126	</queryString>
	127	<field name="work_type_name" class="java.lang.String"/>}}}
	128
	129
	130	)))
2.1	131	* 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.
	138
	139	* Przykład:
1.1	140
2.1	141	(((
	142	\|
1.1	143
2.1	144	* (((
1.1	145	{{{<parameter name="d1" class="java.util.Date"/>
	146	<parameter name="d1_sql_condition" class="java.lang.String">
	147	<defaultValueExpression><![CDATA["[work_type].[date_created] > '" + new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format($P{d1}) + "'"]]></defaultValueExpression>
	148	</parameter>
	149	<queryString language="SQL">
	150	<![CDATA[
	151	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"/>}}}
2.1	157	)))
1.1	158
	159
	160	)))
	161
2.1	162	* 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
1.1	163
2.1	164	== Parametry obowiązkowe i nieobowiązkowe ==
1.1	165
2.1	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.
	172	* Przykład:
1.1	173
2.1	174	(((
	175	\|
	176
	177	* (((
1.1	178	{{{<parameter name="d1" class="java.util.Date"/>
	179	<parameter name="d1_sql_condition" class="java.lang.String">
	180	<defaultValueExpression><![CDATA[$P{d1} == null ? "1=1" : ("[work].[date_created] > '" + new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format($P{d1}) + "'"]]></defaultValueExpression>
	181	</parameter>
	182	<queryString language="SQL">
	183	<![CDATA[
	184	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"/>}}}
2.1	190	)))
1.1	191
	192
	193	)))
	194
2.1	195	* 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.
1.1	196
2.1	197	== Definicja w GUI ==
	198
1.1	199	*
2.1	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.
1.1	205
2.1	206	Typy danych
1.1	207
	208	*
2.1	209	** ciąg znaków - s
	210	** 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
1.1	221
2.1	222	* Unikalna nazwa - składa się z typu danych uzupełnionego o numer
	223	** np. d1, u2, Work3
1.1	224
2.1	225	* Klucz do tłumaczenia - wyświetlany jako opis wejścia
	226	** wprowadzany w nawiasach kwadratowych
	227	** np. [User], [Work_id]
1.1	228
2.1	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.
1.1	233
2.1	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.
1.1	239
2.1	240	* Przykład:
	241	** n1[Work_id],?w2[Web_definition] – szablon z 1 parametrem obowiązkowym i jednym opcjonalnym.
1.1	242
2.1	243	= Rozdzielczość dla różnych baz danych =
1.1	244
2.1	245	* Różne bazy danych używają różnych metod escapowania tabel.
1.1	246	** Mysql - `work`
	247	** MSSQL - [work]
2.1	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.
1.1	254
	255	== <sql> ==
	256
2.1	257	* 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ć.
	261	* Przykład:
1.1	262
2.1	263	(((
	264	\|
1.1	265
	266	{{{<queryString language="SQL">
	267	<![CDATA[
	268	<sql>
	269	SELECT [name] AS work_type_name
	270	FROM [work_type]
	271	</sql>
	272	]]>
	273	</queryString>}}}
	274
	275
	276	)))
	277
	278	== <sqlp> ==
	279
2.1	280	* 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[....]]
	284	* Przykład:
1.1	285
2.1	286	(((
	287	\|
1.1	288
	289	{{{<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>
	291	</parameter>}}}
	292
	293
	294	)))
	295
2.1	296	== Różne SQL dla baz danych ==
1.1	297
2.1	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ń.
	299	* W takim przypadku konieczne jest posiadanie innego SQL dla każdej bazy danych.
	300	* W tym celu stosuje się pary tagów <mysql> i <mssql>.
	301	* Bloki te wprowadzają SQL, który jest używany tylko dla tej konkretnej bazy danych.
	302	* Oznacza to, że jeśli w szablonie znajdują się bloki <mysql> i <mysql>, a pracuję na MSSQL, bloki w części <mysql> są usuwane z szablonu.
	303	* Przykład:
1.1	304
2.1	305	(((
	306	\|
1.1	307
	308	{{{<queryString language="SQL">
	309	<![CDATA[
	310	<mssql>
	311	SELECT [name] AS work_type_name
	312	FROM [work_type]
	313	</mssql>
	314	<mysql>
	315	SELECT `name` AS work_type_name
	316	FROM `work_type`
	317	</mysql>
	318	]]>
	319	</queryString>}}}
	320
	321
	322	)))

Kod źródłowy Wiki Pokročilé výstupy

Interní

Aplikacje

Nawigacja