next »

[Andrew C.]

Is there any hope for a variable to name the report function? eg

Code

function report_superstart(named)
    define
        named, sink, fname string
 
    # lots of code to determine destination
    # eg any of:
    let sink = "pipe" let fname = "some-process"
    let sink = "file" let fname = "/tmp/tmp12345"
    let sink = "printer" let fname = NULL     # will this quietly work without error?
    let sink = "screen" let fname = NULL     # will this quietly work without error?
 
    START REPORT named TO OUTPUT sink DESTINATION fname
 

Please note also the sub-question which is effectively asking if

Code

    START REPORT named to OUTPUT "screen" DESTINATION ""
 

is acceptable to the runtime

[Andrew C.]

cancel the sub-question, I've just successfully tested

TO OUTPUT "screen" DESTINATION "random junk that might be null"

and it's happy.

I guess I only need confirmation that this good behaviour will not be "cleaned up" for unfounded reasons!

So the only real question here is - variable naming the report destination; a quick test shows that trying to use a variable is a failure.

[Sebastien F.]

So the only real question here is - variable naming the report destination; a quick test shows that trying to use a variable is a failure.

Sorry, confused... Do you mean "naming the report routine"?

Using variables in:

Code

 TO OUTPUT var1 DESTINATION var2

works for me...

Seb

[Andrew C.]

Sorry, confused... Do you mean "naming the report routine"?

Yes, that's the plan. I'm trying to clean up and centralise our reporting as part of the exercise for adding GRE. I'm very happy with the powers of TO OUTPUT foo DESTINATION bar - it's let me add a lot of simplicity. The remaining problem is two-fold.

1/ Many of our report executables only contain a single report called (imaginatively enough) report1. Therefore these executables can be serviced by a library routine which chooses the destination - it looks for a command line option and/or other environmental queues.

However there are also plenty of reporting executables which contain more than one REPORT (also it seems unimaginatively called report1, report2, etc etc :-) and these programs therefore have slightly randomised clones of the library routine, replicated as many times as necessary. I say "slightly randomised" because it seems that programmers can't avoid trying to optimise... Adding new destination choices including GRE becomes a tedious hunt for scattered code.

2/ Apart from the traditional destinations that can now be parameterised by using TO OUTPUT/DESTINATION, there's also the problem of choosing to get it rendered via the GRE

Code

        START REPORT report1 TO XML HANDLER xhandler
 

I can easily add this choice into the library routine, but I'm concerned about having all the logic and various calls to fgl_report_* functions cloned out to many places in the code.


So! what I'd like to do is improve the power of the library routine so that it can choose the REPORT target by name. With this I'll be able to remove all cloned code, ensure it's all uniform, and that all reports have identical powers to choose the destination (including GRE with all it's variations) simply by calling the one library routine that knows all the tricks.

As a rough plan, I'm aiming to be able to call something like

Code

function start_report(named, sink, destin)
    # sink and destin can be null implying to look for environmental cues
    # ... lots of logic, possibly setting GRE options and creating a handler,
    # ... or determining values for sink and destin from the environment
 
    if gre_target then
        start report named to xml handler xhandler
    else
        start report named to output sink destination destin
    end if
 

This hypothetical library routine should be able to perform ALL the tasks necessary to nominate the GRE style or traditional destination for all our reports without any cloned local code. The programmers would only have to provide a REPORT and let this library routine take care of the housekeeping.

Also, retaining the traditional destinations will be essential for at least a year or three until GRE and GRW can completely take over. A total cut-over to GRE and GRW just isn't going to happen.

[Sebastien F.]

Thank you Andrew for explaining your needs, this helps us a lot.

So basically, you would like to specify the report name and the XML handler dynamically at runtime... right?

What if we would extend the START REPORT syntax to allow:

  DEFINE rep, out, dst STRING
  LET rep = "report1"
  LET out = "XML HANDLER"
  LET dst = "sax_handler1"
  START REPORT rep TO OUTPUT out DESTINATION dst

Since all internals are dynamic (p-code), I think this should be possible.

There will certainly be a grammar issue with the token following START REPORT (is it a variable or report routine?), so we might need to extend the syntax, not sure.

I will talk with others here and file an enhancement request if you confirm that this would help.

Best regards,
Seb

[Sebastien F.]

Hummm... Just had a look at what the compiler is generating with START REPORT / OUTPUT TO REPORT / FINISH REPORT commands, not sure it's that easy to allow dynamic report name specification: The report routine is actually like a function, the name is written down in the p-code...

But specifying XML HANDLER output and the Sax Handler as DESTINATION should be possible.

Seb

[Andrew C.]

oh - the report name is written directly into the pcode? so the code for REPORT expects a literal string, can't get it off the stack? so that would require changes to the VM. Not to worry, I've got it down to a function call and an IF-statement.

Code

    call report_destination_choice( .... ) returning ct.*    # effectively - ct is actually a global ;-(
    if ct.format == "PDF" or ct.format == "SVG"
      then start report report1 to xml handler ct.handler
      else start report report1 to output ct.format destination ct.destin
    end if
 

If that's the only code that needs to be replicated amongst dozens of programs I'd be very happy; if the only thing changed is the name of the report1 that would be a good result.

Regarding the START REPORT statement, I can't see the DESTINATION being able to handle either the handler object returned from fgl_report_commitCurrentSettings() - I imagine it probably should look something like

Code

    START REPORT report1 TO OUTPUT out DESTINATION dst HANDLER hndlr
 

Where dst must be non-null if out is FILE or PIPE, and hndlr must be non-null if out is XML. This is the only universal one-line syntax I can see; otherwise the 2-line IF-statement I've shown above is more than adequate. I would probably be happy to leave it at that, but it would be a good bonus if the name of the REPORT could be dynamic one day; then even the lines shown above could be reduced. That's probably chasing perfection though!

If more report output formats were added, such as DHTML, Excel, etc then the fact I'm testing for PDF or SVG would need extending in any program using that code; I think I made a mistake not allocating another field in ct to choose the GRE vs. traditional. Sadly, we're in code-freeze for QA and I won't be able to rebuild 100's of programs just for the sake of another field in a global record. I guess I'll save that for the next version!

Cheers and thanks for the feedback

[Sebastien F.]

Oh yes, you are right, the dynamic XML handler specification will certainly require a syntax extension to specify the object variable.
The request is filed as #18012.
Seb

[Rene S.]

> What if we would extend the START REPORT syntax to allow:
>
> DEFINE rep, out, dst STRING
> LET rep = "report1"
> LET out = "XML HANDLER"
> LET dst = "sax_handler1"
> START REPORT rep TO OUTPUT out DESTINATION dst

No. The symbol rep used in START REPORT must be a reference to an REPORT. This suggestion will never be implemented, because it would break existing code: it's legal to define a variable/function/cursor with the same name. The compiler uses different symbol tables.

Rene