Customization Details

Erweiterte Anpassung > Business Logic Customization > Report Generation > Customization Details

After a report exists, there are a number of ways to customize various aspects of the report:

• Customizing Macros

• Customizing Query Builder Types

For reports using custom input pages, additional customizations are supported:

• Customizing the Report Output Format

• Customizing the Report Generation Client

• Customizing the Report Generation URL

Customizing Macros

Customizing macros uses the standard Windchill application services delegation mechanism. This customization example creates a new macro to automatically compute a cutoff time.

1. Create a class that implements the MacroExpressionProcessor interface by performing the following steps:

a. Create a new package or use an existing one. Name the package, for example, myPackage.

b. Create a new class and inherit from the MacroExpressionProcessor interface in the wt.query.report package. Name the class, for example, TimeCutoffMacroProcessor.

c. Compile the class.

d. Fill in the implementation of the buildExpression( ) method. This implementation reads the current system time in milliseconds, computes the new time, and creates a new Date. The Date value is returned as a wt.query.DateExpression. This is necessary because of special handling of dates in SQL expressions to take into account Java representation of dates and timezone settings.

public class TimeCutOffMacroProcessor implements MacroExpressionProcessor {

@Override

public ColumnExpression buildExpression( Element a_element, Map a_parameterMap ) throws QMLException
{
final int DAYS=3;
long currentSeconds= (System.currentTimeMillis()/1000);
long timeSeconds= currentSeconds - (60*60*24*DAYS);
java.util.Date time= new java.util.Date(timeSeconds * 1000);
return (ColumnExpression) DateExpression.newExpression(time, Timestamp.class.getName());

}

@Override

public Object getValue()throws WTException{
final int DAYS=3;
long currentSeconds= (System.currentTimeMillis()/1000);
long timeSeconds= currentSeconds - (60*60*24*DAYS);
java.util.Date time= new java.util.Date(timeSeconds * 1000);

return time;
}
}

e. Fill in the implementation of the getValue( ) method. This value is the actual Date value as computed in the preceding step. This method is called to populate Report Builder input fields when a macro is specified as a default value.

2. Create a logical name for the macro and map it to the implementation class. For example, for logical name "TIME_CUTOFF" and class "myPackage.TimeCutoffMacroExpressionProcessor", the entry would be as follows:

wt.services/svc/default/wt.query.report.MacroExpressionProcessor/
TIME_CUTOFF/java.lang.Object/0=myPackage.TimeCutoffMacroProcessor/singleton

The OOTB entries that exist in dbservice.properties.xconf are:

3. Create a new report query that uses the new macro by performing the following steps:

a. Open the existing Foldered query and save it as a new query, for example, FolderedModified.

b. Remove the criteria based on cabinet name.

c. Add criteria. On the Criteria tab, set the following values as shown in the following table:

Field	Value
Class	Foldered
Attribute	thePersistInfo.modifyStamp
Operator	>
Value	TIME CUTOFF

The TIME_CUTOFF macro is now available for use in reports from the Criteria tab of the Query Builder.

d. Save the query.

4. Execute the report.

For reports that use macros in criteria or default values, Query Builder evaluates the macro at runtime and displays the resulting value in the Criteria pane of the report generation window. It is also possible to use a macro as input in a Criteria pane input field. The macro name should start and end with the $$ characters to denote the value as a macro. For example, to use the out-of-the-box CURRENT_USER_NAME macro in an input field, enter the value as $$CURRENT_USER_NAME$$.

Customizing Query Builder Types

Query Builder uses object model information to present the list of all possible types to build queries against. It does this by searching for all types that implement the wt.fc.NetFactor interface. However, there may be classes that do not implement the wt.fc.Net.Factor interface, yet have subclasses that implement the Persistable interface and therefore can be used in queries. An example is wt.index.Indexable. To allow queries to be built using these types, these types can be listed as resources in a service properties file. The out-of-the-box entry in dbservice.properties handles the Indexable interface as follows:

wt.services/rsc/default/wt.query.report.ClassName/
wt.index.Indexable/java.lang.Object/0=wt.index.Indexable

To customize the list of Query Builder types, new entries can be added. For example, for the class myPackage.myClass, the entry would be as follows:

wt.services/rsc/default/wt.query.report.ClassName/
myPackage.myClass/java.lang.Object/0= myPackage.myClass

This is necessary only if the class does not implement the NetFactor interface, but does have subclasses that implement the Persistable interface.

Customizing the Report Output Format

This customization is supported for reports using custom input pages.

Several report output formats are provided out-of-the-box. All of these formats are intended to be general purpose. That is, they should produce reasonable output from any query. If none of these formats are appropriate, you can modify them or create completely new formats.

CSS Customization

All of the HTML report formats provided, except those derived from Microsoft Word, use a CSS1 stylesheet to specify font, color, size, and spacing details. Use of CSS1 allows these details to be separated from other aspects of page layout and placed into one or more re-usable stylesheets. Therefore, the easiest way to customize these aspects of the HTML reports is to edit the CSS files that they use. For further information about CSS1, refer to the W3C CSS1 specification, currently available at the following URL: http://www.w3.org/TR/REC-CSS1

If you have difficulty with this URL, try the site URL www.w3.org.

Two CSS files are involved: htmlFormat4Print.css and htmlFormat4Screen.css. Both are located in <Windchill codebase>/templates/reports. The htmlFormat4Print.css file is intended to specify the appearance of HTML when printed and the htmlFormat4Screen.css file when viewed on screen. Actually, browsers do not support this aspect of CSS and, therefore, the printed output is controlled by htmlFormat4Screen.css as well. However, you may prefer htmlFormat4Print.css to htmlFormat4Screen.css, which is designed primarily for consistency with other Windchill HTML pages.

To change the CSS stylesheet used by a report or to make larger changes to the output format than possible through CSS1, you must customize XSLT stylesheets as described in the next section.

XSLT Customization

As mentioned earlier, reports are produced by applying XSLT stylesheet transformations to XML query results. This includes all the out-of-the-box formats. XSLT stylesheets are capable of producing not only any HTML layout but also any other XML or text format.

XSLT stylesheets are based on the concepts of templates and rules. Most XSLT stylesheets are largely composed of XML or HTML tags and text that are static; that is, included verbatim in the output. The remainder of the stylesheet is then composed of rules for computing the dynamic portion of the output from the input XML. Depending on the mix of templates and rules, the nature of XSLT customization can vary from simple HTML authoring to pure programming. For the definitive specification on XSLT, refer to the W3C XSLT specification, currently available at the following URL: http://www.w3.org/TR/xslt

If you have difficulty with this URL, try the site URL www.w3.org.

For additional information about XSLT, refer to the “What is XSLT?” link and the “Resources” area currently available at the following URL: http://www.xml.com

If you have difficulty with this URL, try the site URL www.xslinfo.com

Stylesheets Provided

One technique for customizing the output format is to modify one of the XSLT stylesheets that are provided in <Windchill>/codebase/templates/reports/. These stylesheets are described in detail in the following table.

Within fields that specify an XSLT stylesheet in the Windchill UI, you must enter file paths that are relative to <Windchill>/codebase/. For example, excel97WebQuery.xsl must be referenced as "templates/reports/excel97WebQuery.xsl"

XSLT Stylesheet	Standard Format Name	Description
identity.xsl	XML	Performs the identity transformation on the XML query results; that is, it outputs the XML input.
csvFormat.xsl	CSV (Comma Separated Variable)	Produces comma-separated-values format (useful for reading into spreadsheets, and so forth).
tsvFormat.xsl	TSV (Tab Separated Variable)	Produces tab-separated-values format (useful for reading into spreadsheets, and so forth).
simpleHtmlForm at.xsl	HTML	Produces a simple HTML format. Unlike the other HTML formats provided, this format does no extra formatting on numeric columns.
htmlWithSorting .xsl	HTML (with sorting)	Similar to simpleHtmlFormat.xsl except that sorting is provided through hyperlinks on the column headers.
htmlWithMerging .xsl	HTML (with merging)	Similar to simpleHtmlFormat.xsl except that vertically duplicated cells are merged under certain conditions. This is a time-consuming transformation compared to the others provided.
sortedHtmlAsXM L.xsl		Produces the same results as htmlWithSorting.xsl except that the output is well-formed XML rather than traditional HTML, and the results contain additional non-HTML attributes. This is to facilitate application of further XSLT transforms (for example, mergeHTMLCells.xsl) to the result.
mergeHTMLCell s.xsl		Merges cells in HTML (which must be well-formed XML) similar to htmlWithMerging.xsl. Additionally, the input must have extra attributes annotations. This stylesheet is not intended for use directly on the query result XML. Instead, when applied to the results of sortedHtmlAsXML.xsl, the overall effect is to produce HTML with both sorting and merging.
msw2000ls.xsl	Microsoft Word 2000 HTML (Landscape)	Produces a simple HTML format containing Microsoft Word 2000 metadata. When the result is dropped onto Microsoft Word 2000, the originally specified margins, table borders, and so on are preserved. Also, decimal tab stops are specified on floating point data columns. The result has landscape page orientation.
msw2000p.xsl	Microsoft Word 2000 HTML (Portrait)	Same as msw2000ls.xsl except the result has portrait page orientation.
xslfo.xsl	PDF	Produces XSL Formatting Objects, an XML-based standard for high-precision page layout (see http://www.w3.org/TR/xsl). This is referred to as PDF format in standard format lists because the default is to post-process this format to dynamically produce PDFs. This is done through Apache FOP (see http://xml.apache.org/fop) and is controlled by the following user preference: /wt/query/report/template/postprocmap/appl ication/xslfo+xml This format is currently limited by the capabilities of FOP (for example, column widths must be provided rather than being computed from contents) and will improve in the future as FOP improves.
excel97WebQuer y.xsl		Produces a version of Excel Web Query (.iqy) format compatible with both Excel 97 and higher. This Excel format records the URL from which the spreadsheet data came, and can refresh the data from the URL periodically or on demand. For best results with Excel 2000, set the MIME type for Excel Web Query (IQY) files to be application/x-excel-web-query; on downland, this format is then automatically loaded into Excel 2000 only. With Excel 97, you must save the downloaded file and select it from within the Excel 97 'Run Web Query...' command.
excel2000WebQ uery.xsl		Produces a version of Excel Web Query (.iqy) format compatible only with the Excel version currently supported with Windchill. (For details about which third party products are supported, software compatibility and platform support, see Release Calendar.) It uses a new feature in Excel Web queries to attempt to preserve the formatting in the spreadsheet rather than that in the HTML URL data source.
includes/linker.xsl		Provides an XSLT template, generateURLHref, that is used by the provided HTML and XSL FO formats to produce hyperlinks to Windchill objects from XML result nodes that contain additional attribute information provided by the query layer when entire Windchill objects are selected. Object, version, e-mail, and content download links are currently supported.
includes/excelWe bQueryBase.xsl		The shared implementation behind excel97WebQuery.xsl and excel2000WebQuery.xsl. This stylesheet allows stylesheets which include it to specify the relative URL of an XSLT stylesheet that produces HTML tables. The produced Excel Web Query then obtains its data by executing the report (again) but using the specified HTML table format. Thus, by changing this HTML format, one can change the data that appears in Excel as a result of this Web query. Currently both excel97WebQuery.xsl and excel2000WebQuery.xsl use simpleHtmlFormat.xsl.
includes/msw200 0.xsl		The shared implementation behind msw2000ls.xsl and msw2000p.xsl. The page size, margins, and orientation are all specified as inputs. This stylesheet is intended solely for inclusion from other stylesheets.
includes/htmlWit h SortingBase.xsl		The shared implementation behind htmlWithSorting.xsl and sortedHtmlAsXML.xsl. This stylesheet is intended solely for inclusion from other stylesheets.
includes/localize String.xsl		Provides an XSLT named template (that is, a macro) for localizing strings. The implementation uses an XSLT extension function to call back into Java to access Java resource bundles. This stylesheet is intended solely for inclusion from other stylesheets.
includes/urlEnco de.xsl		Provides an XSLT named template for URL encoding. The implementation uses an XSLT extension function to call WTURLEncoder.encode in Java. This stylesheet is intended solely for inclusion from other stylesheets.

Due to the template-based nature of XSLT, some modifications can be made to the provided stylesheets based almost solely on a knowledge of the intended output format (such as HTML). For example, the provided formats that use CSS1 stylesheets generate the references to these files using the following lines in the XSLT stylesheets:

The only part of these lines that is not strictly HTML is the portion within the { } braces which, though similar to JavaScript expression usage, is actually an XSLT XPath expression. In this case, the expression is referencing the variable windchill, which was previously assigned the URL of the Windchill codebase.

XML Resource Bundles

One aspect of the provided XSLT stylesheets is that they use XML resource bundles for localization of text. Rather than producing different versions of each XSLT stylesheet for each locale, the locale-dependent text has been extracted into separate XML files. These are loosely referred to as XML resource bundles, and are retrieved and searched through XSLT based on the locale.

This approach was taken for the following reasons:

• To allow ease of localization by using the same technology, syntax, and tools as those behind XSLT and HTML authoring; that is, XML.

• To allow a tighter coupling between XSLT stylesheets and their localization data. Because relative URLs are used to look up XML resource bundles, they can be installed relative to the XSLT files that reference them, rather than relative to the Windchill codebase.

• To allow localization without dependence on XSLT extension functions.

The XML resource bundles used by the provided XSLT stylesheets are located at <Windchill codebase>/templates/reports/defReportRB_*.xml.

If you decide to use this technique in your own XSLT stylesheets, see the XML resource bundles provided and the XSLT files provided for usage examples. Keep in mind the following issues:

• XML resource bundles must be well-formed XML. For further information, refer to XML.com’s annotated XML specification, currently available at the following URL: http://www.xml.com/pub/axml/axmlintro.html

If you have difficulty with this URL, try the site URL www.xml.com.

The W3C unannotated, original version of the XML specification is currently available at the following URL: http://www.w3.org/TR/REC-xml

If you have difficulty with this URL, try the site URL www.w3.org.

• The encoding listed in the <?xml ...?> header should match that actually used when saving the file and should be one supported by the XML parser used (Xerxes 1.2.2). For example, on Windows NT, you can use the Save as Unicode option in NotePad and specify an encoding of "unicode" in the XML resource bundle.

New Formats

Besides modifying existing XSLT, you can also author entirely new XSLT stylesheets. You can author new stylesheets using the following steps:

1. Author a sample of the intended output format. For example, use an HTML editor to produce a sample of the intended format; create a sample document in Microsoft Office and save it as HTML (this is how the Microsoft Word-based HTML formats were created); or export an Adobe Illustrator drawing as SVG.

The use of Apache Batik, as described in the various chart.xsl stylesheets (see the table in the section on “Stylesheets Provided” earlier in this chapter), provides an alternative means of producing SVG with minimal knowledge of XSLT.

2. Copy static pieces of the sample output to a skeleton XSLT stylesheet, editing or escaping them as necessary to ensure that they are well-formed XML. (All XSLT must be well-formed XML.)

3. Author XSLT to transform the input XML into the dynamic portions of the output, using the sample output as a guide.

The number and complexity of transformations to be done in step 3 can vary greatly from one format to another and largely determine the effort involved in creating a new format. XSLT provides extensive capabilities for sorting, filtering, summing, and combining XML data. Additionally, you can provide XSLT extension functions and elements that call other languages, including Java and JavaScript. See the Saxon documentation for further details.

XML Result Format

Understanding the query result XML format is extremely important to successfully retrieving the desired data from it using XSLT (or any other technique). An outline of this format is shown below. The portions in bold represent dynamic data and ellipses (...) represent omitted items.

<?xml version="1.0" encoding="UTF-8" ?>
<queryResult>
<metadata>
<name>Report Name</name>
<description>Report Description</description>
<objectIdentifier>Report Object Id</objectIdentifier>
<sourceSystem>Windchill Codebase URL</sourceSystem>
<sourceGateway>Windchill Gateway URL</sourceGateway>
<executingPrincipal>
<fullName>User’s Full Name</fullName>
<objectIdentifier>User Object ID</objectIdentifier>
</executingPrincipal>
<timeOfExecution>Time when Executed</timeOfExecution>
<locale>Locale of User</locale>
</metadata>
<auxData>
<dataItem name="requestParam1">value</dataItem>
. . .
<dataItem name="requestParamN">value</dataItem>
</auxData>
</qml>
. . .
</qml>
<actualParameter parameterId="ParamName1"> Value
</actualParameter>
. . .
<actualParameter parameterId="ParamNameN"> Value
</actualParameter>
<result>
<heading tag="column1TagName"
type="Java data type">column header</heading>
. . .
<heading tag="columnNTagName"
type="Java data type">column header</heading>
<row idx="1">
<column1TagName>value</column1TagName>
. . .
<columnNTagName>value</ColumnTagName>
</row>
. . .
<row idx="N">
. . .
</row>
</result>
</queryResult>

If an entire Windchill top-level object (a Persistable) is selected, additional attributes are generated on the column tag element, including the object ID, branch ID (if the object is versioned), and classname of the object. WTUser objects also include email attributes. These attributes are generated primarily to facilitate generation of hyperlinks. Out-of-the-box XSLT stylesheets for HTML and PDF formats use these attributes whenever they are present to produce hyperlinks to the objects.

Additional flexibility for generating hyperlinks is provided by use of the characters $$ in column names. If a column name containing $$ is specified through the Query Builder, an individual cell is not created for it; instead, the name is parsed as follows. If the part of the column name preceding $$ matches another column name that does not contain $$, its data is added to the other column as an attribute, which is determined by the part following $$.

For example, assume the following columns are specified through Query Builder:

• Part

• Part$$branchID

• Part$$type

Each XML row would then contain a Part element like the following:

<Part branchID="dataFromBranchIdColumn"
type="dataFromTypeColumn">dataFromPartColumn</Part>

Rows would not contain individual Part$$branchID or Part$$type columns. This functionality allows you to select the right data to obtain hyperlinks (as described earlier in this section) without having to select entire Persistable objects.

If the column type is java.util.Date, column data is formatted based on the HTTP request's Locale. In addition, the column element has a "value" attribute containing the raw Java string value. If other date-formatting customization is needed, this value could be used.

The table below summarizes the data conveyed by the various top-level elements in the query result XML.

Element	Description
metadata	Meta-information about the query from which the data resulted and the user executing it.
auxData	The request parameters used.
qml	Fully defines the details of the report template query which was made (see <Windchill codebase>/wt/query/qml/qml.dtd for further details).
actualParameters	The query parameters used when executing the query.
result	The column headers and types, and the rows of data.

Using XSLT Stylesheets as Report Formats

To use an XSLT stylesheet as a report format, you must specify it either in the report template user interface or, for report templates that specify their format as “Ask Upon Generate”, upon generation using the HTML report generation form. In either case, two means of specifying formats are allowed: custom and standard.

Specification of custom formats is done using up to two relative or absolute URLs. When the URLs are not absolute, they are relative to the Windchill codebase. When two XSLT URLs are specified, they are applied to the report results in series. The custom specification mechanism allows use of XSLT stylesheets that are not located on the Windchill server and facilitates testing of new stylesheets. It also allows the application of two XSLT stylesheets in a series, which is not possible through the standard format mechanism.

Specification of standard formats is done by selecting one from a list. Most of the provided XSLT stylesheets are part of this list. Additional formats can be added to this list by editing dbservice.properties. These property entries begin with wt.services/rsc/default/wt.query.report.DefaultXSL.

If an existing format is being replaced with a customization, then there may be an additional property entry for the format type that overrides the XSL. This property begins with wt.services/svc/default/com.ptc.core.query.report.client.generation.ReportSAXTransform and should be removed.

The format of these entries is that of the Windchill application services delegation mechanism. If localization of the additional entries is required, edit the Java resource bundle wt.query.template.TemplateResource.

Customizing the Report Generation Client

This customization is supported for reports using custom input pages.

The report generation client consists of an HTML form that can prompt the user for additional report generation input and an HTTP processor that executes the report and applies the XSL transformations. Both of these clients can be customized in the same manner as typical HTML client customizations. For further information, see Customizing HTML Clients Using the Windchill JSP Framework .

In addition, report generation-specific code is available as static methods in a separate class so it can be reused. The ReportTemplateHelper class provides many methods for processing reports (See the wt.query.template.ReportTemplateHelper class entry in your installed Windchill Javadoc for more information).

In previous releases, reports that used subtypes (that is, types created using the Type and Attribute Management utility) needed to be processed using the report commands (See the com.ptc.core.query.report.command.common package entry in your installed Windchill Javadoc for more information). The ReportTemplateHelper APIs now directly support subtypes and customer-created attributes. While report commands are still supported, they are no longer required.

Both of the clients mentioned above rely on a wrapper API developed for XSLT processors. The API can be found in the wt.xml.xslt package entry in your installed Windchill Javadoc for more information.

This API provides the following functionality:

• Independence from individual XSLT implementations (for example, Saxon, the XSLT processor library currently in use)

• A high-level abstraction for XML source that hides the details of a particular implementation (for example, String, Java IO stream, DOM, or SAX)

• A clean API for XSLT operations in Windchill

• Easy-to-use, high-level facilities for complex chaining of XSLT transformations

For additional capabilities beyond those provided through this API, you can use the standard JAXP (Java API for XML Processing) APIs, or access Saxon directly. For further information, see the Saxon Web page, currently available at the following URL:

http://saxon.sourceforge.net

Note, however, that the XSLT library bundled with Windchill may change in the future and that users of the Windchill XSLT and JAXP APIs will be affected less by any such change.

Report Generation Form

The report generation form is used to gather additional report input parameters prior to execution. It consists of two main sections: report parameters and output format.

The report parameters section is built from data specified in the query. Given a report query as an XML source, the ReportTemplateHelper buildParameterTemplates( ) method returns an array of ParameterTemplate instances that represent the parameters of the query. The current client accesses this parameter template data to build the form to prompt the user for input. Note that the processing bypasses any parameter templates if the specified name is included in the HTTP parameters (see the section Customizing the Report Generation URL that follows). This is an indirect way to customize the form. For example, fully specifying all parameter values in the report generation URL would cause no parameter input fields to be generated. Also, the current form processing completely bypasses the form and goes directly to the report execution processing if the XSL specification has been set in the report template and all required parameters (if any) have had values specified in the HTTP parameters.

The output format section is generated based on the XSL specification of the report template object. If one exists, the output format section is bypassed. Otherwise, the input fields for specifying the format are generated. The ReportTemplateHelper getAvailableXSLFormats( ) method is used to build the drop-down choice for the standard XSL.

Report Generation Output

The report generation output relies on the XSLT API. The basic steps are as follows:

1. Generate report data as XML using the ReportTemplateHelper generateXML() method.

2. Obtain a list of XSL stylesheets to apply. This can be specified as an attribute of the report template object or as HTTP parameters. The report template object XSL Specification attribute has precedence over the HTTP parameter values. This logic is implemented in the ReportTemplateHelper.getXSLSpec() method.

3. Create XSLT Transform objects chaining together the array of Stylesheets as necessary. This method is implemented in ReportTemplateHelper.getTransform().

4. Get the post-processor based on the output media type using ReportTemplateHelper.getPostProcessor(). This method uses the preferences mechanism to retrieve the class name of the post-processor.

5. Set the response output type and generate data to the response output stream:

if(postProcessor==null)
{
// No post processor found
response.setHeader("content-type",
ReportTemplateHelper.concatMediaTypeAndEncoding(
outputMimeType, finalSheet.getOutputEncoding()));
transform.outputToStream( response.getOutputStream() );
}
else
(
// Post processor found
response.setHeader("content-type",
ReportTemplateHelper.concatMediaTypeAndEncoding(
postProcessor.getOutputMediaType(),
postProcessor.getOutputEncoding()));
postProcessor.process( transform, response.getOutputStream() );

Creating a New Client

The preceding sections describe the current report generation client and some simple customization points. Using the XSLT API, ReportTemplateHelper methods, and report commands as a basis, there are many ways that an entirely new client could be created. However, detailed discussions on this topic are beyond the scope of this document.

The following are possible example customizations:

• Use the ReportTemplateHelper APIs or report commands that return TypeInstances, QueryResult or Java Swing TableModel objects. These methods can be used in a Java client that uses a specific type of display or must implement additional result set processing.

• Execute report generation in a background or batch mode (for example, running reports nightly) and saving the results in Windchill.

Customizing the Report Generation URL

This customization is supported for reports using custom input pages.

Understanding the report generation URL is important for customizing applications to seamlessly integrate report generation functionality. The URLs that invoke reports can be created dynamically or set up statically (for example, bookmarked) with known URL parameters. There are two types of report generation URLs: Generate Form and Execute Report. The Generate Form URL requests additional input from the user (only if necessary) and generates a form action button that leads to the Execute Report page. The Execute Report page executes the query and returns output to the HTTP request output stream.

Both of these URLs can be edited directly to add URL parameters. Either the original or the edited URL can be bookmarked or used in a hyperlink for future reuse. The URLs can also be generated programatically. The ReportTempateHelper class provides APIs for each type of URL. Several versions, each taking different parameters, are also available. See the getGenerateFormURL( ) and getExecuteReportURL( ) classes entry in your installed Windchill Javadoc for more information.

The Generate Form URL can have parameter values specified directly. For any parameter names that are specified on the URL, the input field is bypassed. In addition, all URL parameters are passed to the Execute Report URL through the form’s action button. The Execute Report URL also derives all report parameter values from the URL parameters (through ReportTemplateHelper methods). If a URL parameter does not exist for a report parameter, then the report parameter’s default value is used. In addition, several other URL parameters, described in the following table, can be used.

URL Parameter Name	Description
jrb	Name of a Java resource bundle for localization of result column headers. The provided XSLT stylesheets are all capable of localizing the result column headers if the name of a Java resource bundle is provided to them. This is intended to allow for re-use of a single query to support multiple locales because the report template user interface provides no means of entering strings per locale.
format	Specifies the format type: formatDelegate or formatCustom. This parameter is used only if the report template object has no XSL specification.
delegateName	Specifies the delegate name to obtain an XSL stylesheet from Windchill codebase. The delegate name must match a value specified in the dbservice.properties file. This parameter is used only if the report template object has no XSL specification and the format URL parameter has a value of "formatDelegate".
xsl1	Specifies a URL for a custom XSL stylesheet. This stylesheet is applied immediately to the query result and can generate direct output to the user, or output suitable for input to another XSL stylesheet. This parameter is used only if the report template object has no XSL specification and the cformat URL parameter has a value of "formatCustom".
xsl2	Specifies a URL for a custom XSL stylesheet. This stylesheet is applied to the output of the first XSL stylesheet (specified by xsl1) and should generate output to the user. This parameter is used only if the report template object has no XSL specification, the format URL parameter has a value of "formatCustom", and the xsl1 URL parameter has been specified.

War dies hilfreich?