Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
document styles 1
- Thread starter jpuk
- Start date
- Thread starter
- #3
-
1
- #4
you can do it all in one XSL.
# of metric columns is an element available to you in the XML node structure...or you could do a simple loop to count the max number of 'mv' nodes.
anyway, if you are running 2 reports, query the XML of the first report, and assign a value to a variable based off the query you run against the XML node structure of G1
[green]
dim iMC
iMC = ObjXMLNode.selectSingleNode("/mi/rit/vw/gr"
.getAttribute("brc"
[/green]
with the second XML result set you could append a result to the XML based off the result of the above....you could also have a special XSL be applied if the iMC variable = 0.
Chael
# of metric columns is an element available to you in the XML node structure...or you could do a simple loop to count the max number of 'mv' nodes.
anyway, if you are running 2 reports, query the XML of the first report, and assign a value to a variable based off the query you run against the XML node structure of G1
[green]
dim iMC
iMC = ObjXMLNode.selectSingleNode("/mi/rit/vw/gr"
.getAttribute("brc" [/green]
with the second XML result set you could append a result to the XML based off the result of the above....you could also have a special XSL be applied if the iMC variable = 0.
Chael
- Thread starter
- #5
this comes out of the report XML...this would be something that you could include in an XSL and apply to a report in a doc object...of course in that situation you'd probably want to use a javascript function in the XSL and do some logic based off of the result of that node query.
TN5600-007-0029 might be a good technote to read to get you started on building custom XSLs...
TN5600-007-0029 might be a good technote to read to get you started on building custom XSLs...
- Thread starter
- #7
Chael
I have a stylesheet on my second report within the document - can that stylesheet reference the brc attribute from the first report if so how - please give an example of the xsl. wouldn't the example from above (ObjXMLNode.selectSingleNode("/mi/rit/vw/gr".getAttribute("brc" ) only get the info from the report it's run against.
many thanks
I have a stylesheet on my second report within the document - can that stylesheet reference the brc attribute from the first report if so how - please give an example of the xsl. wouldn't the example from above (ObjXMLNode.selectSingleNode("/mi/rit/vw/gr"
.getAttribute("brc" ) only get the info from the report it's run against.many thanks
well, getting the reports to 'inform' one about the results of the other is hard to do via a doc object...if you were to do this via a custom .asp then you could translate the results of one report to the second much easier.
I'd like to step back and approach this problem not just from the XSL, but from what are you trying to do in the first place. Basically, if Report 1 (R1) returns empty rows or no data, then you want the display of R2 to simply add an extra line to the rendered report display.
Could you combine the 2 reports? -- thus you have one XML set to play with.
Could you run a post SQL statement from R1 to populate a table based off of the row counts and have that be a metric in R2?
Could you put 3 reports on your doc Object R1,R2,R3 and have R1 and R2 be the same reports? If your empty line can go at the end of the display of R2, you could have an XSL that decides whether or not R1/R3 actually returned data, and if not you can set your R3 XSL to simply append an extra "<TR><TD>...your data here...</TD></TR>" type of result...
One trick that you can do with XSLs in doc Objects is to strip out the <TABLE> tags in the XSLs and encase the report/XSL combos with the doc Object HTML so that all the reports really only look like one report. For example:
Doc Object 1
[blue]
<HTML>
<BODY>
<TABLE>[/blue]
[green]
XSL 1 (R1)
XSL 2 (R2)
XSL 3 (R1)
[/green]
[blue]
</TABLE>
</BODY>
</HTML>
[/blue]
...so in the above instance, the XSLs are individual reports that only render <TR> AND <TD> type statements. Whe you run this doc Object, R1 and R3 (same report) will only run once, but you can use the resulting XML as many times as you need to. So you really aren't retaining the 'state' of R1 to the XSL to R2, but by employing this method you can write an XSL that returns a result only if there is no result for the report.
Sorry for the long-winded response, but in writing this I think the solution to your problem lies in combining many multiple reports to actually look like one report.
If you don't think this will work we can try it from another angle...I still think you can use the XML parsing string I gave you to 'test' the result set in the XSL....or you could use the XSL:test tags as well. Lots of options here.
Chael
I'd like to step back and approach this problem not just from the XSL, but from what are you trying to do in the first place. Basically, if Report 1 (R1) returns empty rows or no data, then you want the display of R2 to simply add an extra line to the rendered report display.
Could you combine the 2 reports? -- thus you have one XML set to play with.
Could you run a post SQL statement from R1 to populate a table based off of the row counts and have that be a metric in R2?
Could you put 3 reports on your doc Object R1,R2,R3 and have R1 and R2 be the same reports? If your empty line can go at the end of the display of R2, you could have an XSL that decides whether or not R1/R3 actually returned data, and if not you can set your R3 XSL to simply append an extra "<TR><TD>...your data here...</TD></TR>" type of result...
One trick that you can do with XSLs in doc Objects is to strip out the <TABLE> tags in the XSLs and encase the report/XSL combos with the doc Object HTML so that all the reports really only look like one report. For example:
Doc Object 1
[blue]
<HTML>
<BODY>
<TABLE>[/blue]
[green]
XSL 1 (R1)
XSL 2 (R2)
XSL 3 (R1)
[/green]
[blue]
</TABLE>
</BODY>
</HTML>
[/blue]
...so in the above instance, the XSLs are individual reports that only render <TR> AND <TD> type statements. Whe you run this doc Object, R1 and R3 (same report) will only run once, but you can use the resulting XML as many times as you need to. So you really aren't retaining the 'state' of R1 to the XSL to R2, but by employing this method you can write an XSL that returns a result only if there is no result for the report.
Sorry for the long-winded response, but in writing this I think the solution to your problem lies in combining many multiple reports to actually look like one report.
If you don't think this will work we can try it from another angle...I still think you can use the XML parsing string I gave you to 'test' the result set in the XSL....or you could use the XSL:test tags as well. Lots of options here.
Chael
- Thread starter
- #9
chael,
our build is similar to you last option
<html>
<table>
<Report1>
<Report2>
</table>
<html>
if report2 returns no data then i want to build a blank <tr> with an equivilent number of <td>0.00</td> as in the first report - my problem is that grid two provides me with no information as to the number of columns i need to build.
so I need a way to get the number of metric columns in report1 (which always produces data) - i thought this might be possible in the xsl of subsequent grids.
our build is similar to you last option
<html>
<table>
<Report1>
<Report2>
</table>
<html>
if report2 returns no data then i want to build a blank <tr> with an equivilent number of <td>0.00</td> as in the first report - my problem is that grid two provides me with no information as to the number of columns i need to build.
so I need a way to get the number of metric columns in report1 (which always produces data) - i thought this might be possible in the xsl of subsequent grids.
this is going to be hard to do in a document object but it could be done using the web API...you can run a document through the API and get the XML for the whole document...
<dod>
<mi>all nodes for report 1...</mi>
<mi>all nodes for report 2...</mi>
<mi>all nodes for report 3...</mi>
</dod>
with all the report XML in one blob you can do whatever you want with one XSL.
If this is a one-time customization maybe you could do a little handywork with document.asp and before the DisplayDocument function call you could check the reportID that is being passed and build your own custom display function.
I'm sure there are like 500 better ways to do it...
<dod>
<mi>all nodes for report 1...</mi>
<mi>all nodes for report 2...</mi>
<mi>all nodes for report 3...</mi>
</dod>
with all the report XML in one blob you can do whatever you want with one XSL.
If this is a one-time customization maybe you could do a little handywork with document.asp and before the DisplayDocument function call you could check the reportID that is being passed and build your own custom display function.
I'm sure there are like 500 better ways to do it...
- Thread starter
- #11
He has 2 reports on a docObject. Based off the results of one he wants to affect the rendering of the second one. This is more of and XSL/XML problem.
If you can't customize the web code, then your docObject needs some way to retain state. As I continue to think about this problem, I think another possible solution would be to have a javascript function in the HTML template that could pass the results of the first grid to the second grid. The issue here, as it always has been, is that you need to retain state info but XSLs in this instance are stateless. If you can't customize the OOB code, then you need to do some trickery within the document objects themselves. I still think there are better ways of approaching your problem (like having a metric in grid 2 that contains information about grid 1 so that you can do everything in one XSL.
Well, I'm done spending any more time on this topic. Good luck buddy.
Chael
If you can't customize the web code, then your docObject needs some way to retain state. As I continue to think about this problem, I think another possible solution would be to have a javascript function in the HTML template that could pass the results of the first grid to the second grid. The issue here, as it always has been, is that you need to retain state info but XSLs in this instance are stateless. If you can't customize the OOB code, then you need to do some trickery within the document objects themselves. I still think there are better ways of approaching your problem (like having a metric in grid 2 that contains information about grid 1 so that you can do everything in one XSL.
Well, I'm done spending any more time on this topic. Good luck buddy.
Chael
- Status
Similar threads
- Locked
- Question
- Locked
- Question