Associates the Zen report with a Zen application. A Zen report's application provides the default values for built-in class parameters. A value specified in the Zen Report itself takes priority over the value from the application. If you do not specify an application, the Zen report uses
%ZEN.Report.defaultApplication.
If you define a new class parameter on the Zen report, there is no automatic logic to inherit the value from the Application. You need to define the parameter in both the report and the application. You can then use the macro $$$GETPARAMETER to get the value from the application, as illustrated in the following example:
/// User-defined parameter. Defined on Report and on Application.
Parameter COPYFROMAPP = "FromRpt";
Property CopyFromApp As %String(ZENURL = "CopyFromApp");
/// This callback is invoked after this report is instantiated
/// and before it is run.
Method %OnBeforeReport() As %Status
{
Set:..CopyFromApp="" ..CopyFromApp=$$$GETPARAMETER("COPYFROMAPP")
Quit $$$OK
}
Identifies the
to-excel stylesheet that controls XHTML output for the Zen report. If a Zen report class has both a non-empty, valid EXCELSTYLESHEET string
and an XData ReportDisplay block, the EXCELSTYLESHEET parameter takes precedence over the XData block.
This string can be any of the following:
-
The URI of any valid XSLT stylesheet. You can use any URI that returns appropriate XSLT. Relative URIs are handled with respect to the current URI.
-
The name of a file containing a valid XSLT stylesheet. The file must reside in the directory specified in the
CSP Files Physical Path for the Web Application definition for the Zen report. For example, if the URI for the Zen report class is:
http://localhost:57772/csp/myNamespace/mine.MyReport.cls
Then the syntax for the EXCELSTYLESHEET parameter is:
Parameter EXCELSTYLESHEET="data.xsl";
-
An empty string. In this case, the class generates a to-EXCEL stylesheet using the specification in its XData ReportDisplay block.
Warning:
Do not use a URI string that refers to the Zen report class in which the EXCELSTYLESHEET parameter appears. Doing so results in infinite recursion, which leads to an <UNDEFINED> error and the creation of hundreds of processes.
The
XSLFOSTYLESHEET parameter performs the same function in reports that generate PDF output, and the
HTMLSTYLESHEET parameter performs the same function in reports that generate HTML output.
Identifies the
to-HTML stylesheet that controls XHTML output for the Zen report. If a Zen report class has both a non-empty, valid HTMLSTYLESHEET string
and an XData ReportDisplay block, the HTMLSTYLESHEET parameter takes precedence over the XData block.
This string can be any of the following:
-
The URI of any valid XSLT stylesheet. You can use any URI that returns appropriate XSLT. Relative URIs are handled with respect to the current URI.
The URI string can refer to a to-HTML stylesheet created by another Zen report class in the same namespace. Use the
$MODE=tohtml query parameter to specify that you want to use the to-HTML output from that class, as follows:
Parameter HTMLSTYLESHEET="MyApp.Report.cls?$MODE=tohtml";
-
The name of a file containing a valid XSLT stylesheet. The file must reside in the directory specified in the
CSP Files Physical Path for the Web Application definition for the Zen report. For example, if the URI for the Zen report class is:
http://localhost:57772/csp/myNamespace/mine.MyReport.cls
Then the syntax for the HTMLSTYLESHEET parameter is:
Parameter HTMLSTYLESHEET="data.xsl";
-
An empty string. In this case, the class generates a to-HTML stylesheet using the specification in its XData ReportDisplay block.
Warning:
Do not use a URI string that refers to the Zen report class in which the HTMLSTYLESHEET parameter appears. Doing so results in infinite recursion, which leads to an <UNDEFINED> error and the creation of hundreds of processes.
The
XSLFOSTYLESHEET parameter performs the same function in reports that generate PDF output, and the
EXCELSTYLESHEET parameter performs the same function in reports that generate Excel spreadsheet output.
Usually the choice of PDF rendering engine is XEP or FOP, each of which supports the following command line option to introduce the name of the PDF output file for the transformation from XSL-FO to PDF:
This is the default value for PDFSWITCH.
If you want Zen reports to use a PDF rendering engine other than XEP or FOP, this engine might require a different command line option to identify its PDF output file. You must specify the correct option syntax using the PDFSWITCH class parameter in your Zen report class. For example:
Parameter PDFSWITCH = "-o";
Specifies the location of a PostScript printer, such as:
Parameter PS = "\\devD630\BrotherH";
To send a report directly to the specified PostScript printer, without creating an intervening PDF file, set the
DEFAULTMODE class parameter to
"ps". You can also set $MODE=ps in the URI string and set the URI query parameter
$PS to the location of the PostScript printer.
(Firefox only) Controls the filename suggested by the browser when you choose
File > Save As to save the final output of running a Zen report in XHTML or PDF format. If you do not supply a value for the REPORTNAME class parameter, the browser uses the Zen report class name as the suggested filename.
The location for saved Zen report output is as follows:
Where
C:\MyCache is the name of your installation directory and
myApp is the namespace where the Zen report class resides.
REPORTNAME does not work with Internet Explorer, Chrome, or Safari. In these cases the <report> must have a title attribute set; that title is used in the
File > Save As prompt. REPORTNAME works with Firefox when XHTML is generated on the server side. Server-side generation takes place when the output format is PDF, when XSLTMODE or $XSLT is set to "server" (the default), or when you have instructed Zen reports to embed XSLT instructions within the output XHTML by setting EMBEDXSL or $EMBEDXSL to 1.
Unlike most parameters that share a name except for the $ (dollar sign), there is no relationship between REPORTNAME and the URI query parameter
$REPORTNAME.
Lets you override the default behavior, which is to generate HTML5 when the browser supports it.
When UseHTML5 is
"" (null), which is the default value, a report rendering in a browser generates HTML5 if it has determined that the browser supports HTML5. When UseHTML5 is non-null, the boolean value determines whether to generate HTML5 or not regardless of whether the browser supports HTML5. You can use the corresponding UseHTML5 property when using
GenerateReport.
USEINSTANCEHOSTNAMEONRELATIVEURLS
When a Zen report is shared among several servers for load balancing purposes, and when the Zen report uses elements such as
<xslinclude> that refer to other Zen or CSP pages, the external PDF rendering engine needs a way to come back to the Caché CSP Gateway instead of going all the way back to the virtual IP. The attempt to go back to the virtual IP results in an error, since the gateway does not recognize that address.
It is possible to configure a Zen report class so that it substitutes the configured instance host name for the CSP Gateway whenever it constructs a full URL from the relative paths contained in
<xslinclude> and other elements that supply URLs. To enable this feature, set the USEINSTANCEHOSTNAMEONRELATIVEURLS class parameter to 1 (true). The default is 0 (false).
Usually the choice of PDF rendering engine is XEP or FOP, each of which supports the following command line option to introduce the name of the XSL-FO data file for the transformation from XSL-FO to PDF:
This is the default value for XMLSWITCH.
If you want Zen reports to use a PDF rendering engine other than XEP or FOP, this engine might require a different command line option to identify its XSL-FO data file. You must specify the correct option syntax using the XMLSWITCH class parameter in your Zen report class. For example:
Parameter XMLSWITCH = "-d";
Identifies the
to-XSLFO stylesheet that controls XHTML output for the Zen report. If a Zen report class has both a non-empty, valid XSLFOSTYLESHEET string
and an XData ReportDisplay block, the XSLFOSTYLESHEET parameter takes precedence over the XData block.
This string can be any of the following:
-
The URI of any valid XSLT stylesheet. You can use any URI that returns appropriate XSLT. Relative URIs are handled with respect to the current URI.
The URI string can refer to a to-XSLFO stylesheet created by another Zen report class in the same namespace. Use the
$MODE=toxslfo query parameter to specify that you want to use the to-XSLFO output from that class, as follows:
Parameter XSLFOSTYLESHEET="MyApp.Report.cls?$MODE=toxslfo";
-
The name of a file containing a valid XSLT stylesheet. The file must reside in the Web Application directory for the namespace in which the Zen report class resides. For example, if the URI for the Zen report class is:
http://localhost:57772/csp/myNamespace/mine.MyReport.cls
Then the syntax for the XSLFOSTYLESHEET parameter is:
Parameter XSLFOSTYLESHEET="data.xsl";
-
An empty string. In this case, the class generates a to-XSLFO stylesheet using the specification in its XData ReportDisplay block.
Warning:
Do not use a URI string that refers to the Zen report class in which the XSLFOSTYLESHEET parameter appears. Doing so results in infinite recursion, which leads to an <UNDEFINED> error and the creation of hundreds of processes.
The
HTMLSTYLESHEET parameter performs the same function in reports that generate HTML output, and the
EXCELSTYLESHEET parameter performs the same function in reports that generate Excel spreadsheet output.
Usually the choice of PDF rendering engine is XEP or FOP, each of which supports the following command line option to introduce the name of the XSL-FO stylesheet file for the transformation from XSL-FO to PDF:
This is the default value for XSLSWITCH.
If you want Zen reports to use a PDF rendering engine other than XEP or FOP, this engine might require a different command line option to identify its XSL-FO stylesheet file. You must specify the correct option syntax using the XSLSWITCH class parameter in your Zen report class. For example:
Parameter XSLSWITCH = "-s";
A value of
"1.0" or
"2.0" causes the XSLT for this report to be processed as XSLT Version 1.0 or XSLT Version 2.0, respectively.
"1.0" is the default. The XSLTVERSION value affects the XSLT that a Zen report generates as well as any that it encounters in <xslt> sections, XData blocks, or external files. A user can override the current XSLTVERSION setting for the report class by providing an
$XSLTVERSION parameter in the URI when invoking the Zen report from a browser.
XSLT 1.0 is the default, and requires no special preparation. XSLT 2.0 represents significant changes from XSLT 1.0, including more careful type checking and more options for controlling the flow of logic within the transformation. XSLT 2.0 transformations are not likely to work if they are interpreted as XSLT 1.0. Problems in the other direction occur less frequently: XSLT 1.0 transformations often work when interpreted as XSLT 2.0. However, they can produce different output than when interpreted as XSLT 1.0, or fail to work. There are no compatibility guarantees.
This section lists the Zen report class parameters that contribute specialized XSLT processing instructions. These class parameters address problems that can occur when the browser is Internet Explorer and the Zen report class is marked as private by setting its CSP class parameter PRIVATE to 1 (True). If this is not your situation, you do not need these additional class parameters.
When invoked in the browser to generate XHTML, a Zen report generates XML, sends this XML to the client, then transforms this XML to XHTML on the client by following an
xml-stylesheet processing instruction. The attributes for this instruction appear as query parameters in a URI string sent to the browser. Internet Explorer only understands URI instructions that have one parameter after the
? question mark. Problems can occur when the generated
xml-stylesheet instructions for a Zen report class contains multiple parameters and the browser is Internet Explorer. This is particularly true if the Zen report class is marked as private by setting its CSP class parameter PRIVATE to 1 (True).
For this reason, many of the Zen report class parameters provide the information needed in
xml-stylesheet processing instructions, so that this information does not need to appear in the URI query string. Once you have correctly configured the class parameters, Zen handles these instructions appropriately, regardless of the browser. The following list describes the Zen report class parameters of this type.
When EMBEDXSL=1 (true) Zen generates XSLT instructions embedded within the output XHTML. The default for EMBEDXSL is 0 (false), in which case Zen generates a separate XSLT file, rather than embedding the instructions in the XHTML file.
Embedding the XSLT instructions brings up the issue of uniqueness for XML elements in the output file. The default namespace
http://www.w3.org/1999/xhtml cannot be the namespace for all the generated XML elements if the generated XML and XSLT are combined in a single HTTP response. To ensure fully qualified XML names, InterSystems recommends when you set EMBEDXSL=1 you also provide a namespace name and prefix by providing values for REPORTXMLNAMESPACE and REPORTXMLNAMESPACEPREFIX in the Zen report class, for example:
Parameter EMBEDXSL=1;
Parameter REPORTXMLNAMESPACE="http://www.example.com";
Parameter REPORTXMLNAMESPACEPREFIX="SR";
Then the generated XML looks like the following example and the XSLT is updated to work with this XML:
<SR:myReport xmlns:SR="http://www.example.com"
runTime='2008-03-27 00:01:49'
runBy='_SYSTEM' author='BOB' month='Jan'>
<SR:SalesRep name='Jack'>
<SR:record id='331' number='5'>
<SR:date>2005-01-20</SR:date>
<SR:customer>Yoyomo Inc.</SR:customer>
</SR:record>
<SR:record id='537' number='9'>
<SR:date>2005-01-20</SR:date>
<SR:customer>XenaData.com</SR:customer>
</SR:record>
<!-- more records omitted -->
</SR:SalesRep>
</SR:myReport>
You can omit the REPORTXMLNAMESPACE or REPORTXMLNAMESPACEPREFIX parameters from the Zen report class. When EMBEDXSL=1 and these parameters are not set, they default as follows:
-
REPORTXMLNAMESPACE defaults to:
-
REPORTXMLNAMESPACEPREFIX defaults to:
When an external
DATASOURCE is identified, EMBEDXSL is ignored.
A user can override the current EMBEDXSL setting for the report class by providing a
$EMBEDXSL parameter in the URI when invoking the Zen report from a browser.
Allows you to specify the processing mode to use if the URI parameter $MODE is not specified. DEFAULTMODE serves this same purpose, but cannot be used if the Zen report class is marked as private by setting its CSP class parameter PRIVATE to 1 (True). STYLESHEETDEFAULTMODE is provided to help in this case. Otherwise it is not needed.
If your Zen report uses both
DEFAULTMODE and STYLESHEETDEFAULTMODE, you must set them carefully. Be aware that if both are set and the URI parameter $MODE is not specified, then STYLESHEETDEFAULTMODE overrides DEFAULTMODE as the default style mode.
If you want to use the STYLESHEETDEFAULTMODE, and your desired output format is:
-
Excel spreadsheet, use this combination of settings and values:
-
Class parameter DEFAULTMODE may have any value
-
-
-
XHTML, use this combination of settings and values:
-
Class parameter DEFAULTMODE may have any value
-
-
-
PDF, use this combination:
-
Class parameter DEFAULTMODE may have any value
-
-
-
XML, use this combination:
-
Class parameter DEFAULTMODE may have any value
-
Omit the class parameter STYLESHEETDEFAULTMODE
-
The full list of possible values for STYLESHEETDEFAULTMODE is:
-
"tohtml" To-HTML stylesheet in XSLT format
-
"toxslfo" To-XSLFO stylesheet in XSLT format
Allows you to specify where XSLT transformation occurs, without adding to the number of query parameters in the URI string for the Zen report. XSLTMODE can have the value
"browser" or
"server". This causes the XSLT to be processed, and XHTML to be generated, on the server or browser, respectively.
XSLT processing is expensive; it could compromise the scalability of the application to shift XSLT processing to the server. However, the XSLTMODE option is provided to allow that flexibility. The default XSLTMODE is
"server". Also see
USETEMPFILES.
A user can override the current XSLTMODE setting for the report class by providing a
$XSLT parameter in the URI when invoking the Zen report from a browser.
When the output mode is PDF, some processing always occurs on the server, because the third-party PDF generator engine (RenderX or FOP) runs on the server.