[Dev] Reports as Tools

[Brett Wooldridge]

Leo,

Some of this stuff is already baked, so while I appreciate the input not all can be accommodated especially in this release.  The ReportJob is not the same job as a ScriptToolJob job (if you've been following my check-ins), they are very different.  They live in different bundles but both provide metadata through the PluginProvider via extensions.  As a possible future re-factor they could be brought closer together.  But they are so different I don't see the point of mashing together at the implementation side of things.  In fact I think it would be poor encapsulation.  I should be able to (and can) pull the Birt bundle and not have reports but still have tools and vise-versa.

A script tool that chooses to generate HTML is still very different than a Birt report.  In the case of script tools what we store is the raw output of the tool (in this example HTML).  The output of that tool would always and forever only be viewable as HTML because that is what is stored.  In the case of a Birt report the only thing that is stored is the intermediate format.  There is no output format (CSV, HTML, PDF, XLS).  Output format is a view-time decision.

In the future we should allow tool output to act as a DataSet for a Birt report because this winds up being much more powerful than a tool generating HTML directly.  If you've ever had to generate complex HTML programmatically (including JavaScript and image links) you know there is not much more disgusting.  By allowing the output of a tool to be piped through the Birt engine, we enable the design of output (including charts, etc.) through the Birt designer rather than coded by hand in the tool.

-Brett

On 3/25/08 6:55 AM, "Leo Bayer" <lbayer at alterpoint.com> wrote:

Brett,

I would like it for reports to be tools as far as the client is
concerned.  This includes the metadata, scheduling, and output.  So to
run a report I would schedule a tools job (using the same job type as a
script tool).  If reports are just tools then the output can be shared.
For instance an arbitrary tool can have 'html' as the output type and
running it would make available the HTML.  In the report case it just
happens that BIRT is what generated the output.  As far as the UI is
concerned what makes it a Report as opposed to something else is that it
is in the "Report" group (or conceivably instead of groups, just use the
tool type for the group).

Doing this would presumably mean that there is only one job on the
server for running any type of tool.  A client only needs to know how to
manage a tool and how to show output for a tool.  To me this seems like
a nice factorization so there are fewer pieces.  Also it means that a
report could be written in perl if someone really wanted to.  And our
traditional tools could also be written in BIRT if they wanted to (by
having the report's output type being our traditional CSV).

This stream of conciousness brought to you by
 - Leo

_______________________________________________
Dev mailing list
Dev at ziptie.org
http://mailman.ziptie.org/listinfo/dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ziptie.org/pipermail/dev/attachments/20080324/bd90b34d/attachment.html