cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - New to the community? Learn how to post a question and get help from PTC and industry experts! X

Generate-Report Webject

DerekBotfield
1-Visitor

Generate-Report Webject

I am trying to get a Query Builder report using the Generate-Report Webject.

My report retrieves the URLs of a set of WTChangeRequest2 objects. Or at least it does through the Query Builder interface:

i.e.:Invoked from the Query builder, the query returns (among others) a hyperlink to: http://xxxxxx/Windchill/servlet/WindchillAuthGW/wt.enterprise.URLProcessor/URLTemplateAction?u8&oid=OR%3Awt.change2.WTChangeRequest2%3A267047679&action=ObjProps

named: "105169 - 0000-000-000"

But, invoked from the Generate-Report webject, I just get the name, i.e.:"105169 - 0000-000-000"

Does anyone know if and how it is possible to get the URL, rather than the name when using the Generate-Report webject?

Many Thanks!

Derek

5 REPLIES 5

Derek,

The URLs in report builder's reportsare generated by the xsl post-processor. What you get from the webject is the input to the xsl. Thusyou need toget the object-id from the report and generate the URL yourself by adding a prefix and a suffix. Ireckon there is also a webject that lets you run the xsl processor too, by I have never used it.

Actually, the OOTB report builder is not able to create an URL that would pass through the OOTB Xsl processors. This isdue to special characters (namely ;"/" ":") which are replaced by html equivalents.

In order to generate my own URLs in the builder, I had to modify an XSL template.

HTH,

Vincent

A (detailed) SPR should be filed for this.

--
Jess Holle

Vincent Quesnoit wrote:
>
> Derek,
>
> The URLs in report builder's reports are generated by the xsl
> post-processor. What you get from the webject is the input to the xsl.
> Thus you need to get the object-id from the report and generate the
> URL yourself by adding a prefix and a suffix. I reckon there is also a
> webject that lets you run the xsl processor too, by I have never used it.
>
> Actually, the OOTB report builder is not able to create an URL that
> would pass through the OOTB Xsl processors. This is due to special
> characters (namely ;"/" ":") which are replaced by html equivalents.
>
> In order to generate my own URLs in the builder, I had to modify an
> XSL template.
>
> HTH,
>
> Vincent
>
>
>
>

Jess,

I do not know how to file an SPR, Ionly know how to make calls.

My previous post was misleading, as I did not mention the rightproblem characters.

What actually happens is that the "<" and ">" characters are replaced by < and> by the standard xsl converters for html, probably to preventgeneration ofimproper html data. For that reason, I cannot build a field directly as proper html that would be passed "as is", thus I cannot output a field that would be an htmllink.

I slightly changed one of the "to html" output formatters to change fields that started with "http" into proper I am not sure whether the standard xsl formatters should provide that kind of functionnality. If they did, the best (IMO) would be to define an escape sequence to protect the < and > characters from being modified.

A (detailed) SPR should be filed for this.

--
Jess Holle

Vincent Quesnoit wrote:
>
> Derek,
>
> The URLs in report builder's reports are generated by the xsl
> post-processor. What you get from the webject is the input to the xsl.
> Thus you need to get the object-id from the report and generate the
> URL ...















Vincent Quesnoit wrote:
>
> Jess,
>
> I do not know how to file an SPR, I only know how to make calls.
>
Sorry -- that's what I meant, i..e. to open a call and request that a
software issue be filed (which internally is known as an SPR).

I don't believe that's appropriate, however, given the details you've
now provided.
>
> My previous post was misleading, as I did not mention the
> right problem characters.
>
> What actually happens is that the "<" and ">" characters are replaced
> by < and > by the standard xsl converters for html, probably to
> prevent generation of improper html data. For that reason, I cannot
> build a field directly as proper html that would be passed "as is",
> thus I cannot output a field that would be an html link.
>
Ah -- there's no intent to support HTML "as is" here. As you note, not
allowing this prevents < and > characters in the data (e.g. in a
description) from producing improper, garbled HTML output. It also
prevents XSS attacks -- something to be careful of whenever you're
generating HTML. All untrusted data (data that /may /have come from a
user at some point in time) must have <, >, &, ', and " characters
HTML/XML escaped. If you output HTML "as is" then you need to do such
escaping on all untrusted data used to produce these HTML snippets prior
to forming these snippets.

There is built-in support in the ReportTemplate output for generating a
number of types of links. This is /briefly /described in the report
generation chapter of the customizer's guide. Essentially if you have
columns named "Part", "Part$$branchId", and "Part$$type" containing the
text you wish to show for the link label, the branch id, and class name,
respectively, then you'll get a Part column containing links to the
object's version info pages. Besides "branchID" and "type", the other
such supported fields would appear to be "objectId" (used with "type"
like "branchId"), "email" (used to specify an e-mail address and thus
get a mailto: link), and "href" (which specifies a full href as-is).

--
Jess Holle

Thanks to Jess and Vincent:

I ended up constructing the appropriate URL from the individual parts, along the lines outlined in Jess' message.

Many Thanks,

Derek

In Reply to Jess Holle:

@Vincent Quesnoit wrote:
>
> Jess,
>
> I do not know how to file an SPR, I only know how to make calls.
>
Sorry -- that's what I meant, i..e. to open a call and request that a
software issue be filed (which internally is known as an SPR).

I don't believe that's appropriate, however, given the details you've
now provided.
>
> My previous post was misleading, as I did not mention the
> right problem characters.
>
> What actually happens is that the "<" and ">" characters are replaced
> by < and > by the standard xsl converters for html, probably to
> prevent generation of improper html data. For that reason, I cannot
> build a field directly as proper html that would be passed "as is",
> thus I cannot output a field that would be an html link.
>
Ah -- there's no intent to support HTML "as is" here. As you note, not
allowing this prevents < and > characters in the data (e.g. in a
description) from producing improper, garbled HTML output. It also
prevents XSS attacks -- something to be careful of whenever you're
generating HTML. All untrusted data (data that /may /have come from a
user at some point in time) must have <, >, &, ', and " characters
HTML/XML escaped. If you output HTML "as is" then you need to do such
escaping on all untrusted data used to produce these HTML snippets prior
to forming these snippets.

There is built-in support in the ReportTemplate output for generating a
number of types of links. This is /briefly /described in the report
generation chapter of the customizer's guide. Essentially if you have
columns named "Part", "Part$$branchId", and "Part$$type" containing the
text you wish to show for the link label, the branch id, and class name,
respectively, then you'll get a Part column containing links to the
object's version info pages. Besides "branchID" and "type", the other
such supported fields would appear to be "objectId" (used with "type"
like "branchId"), "email" (used to specify an e-mail address and thus
get a mailto: link), and "href" (which specifies a full href as-is).

--
Jess Holle

Announcements


Top Tags