Home » Archived » BIRT » ROM Feedback: Scripting
|
| Re: ROM Feedback: Scripting [message #1628 is a reply to message #672] |
Thu, 06 January 2005 01:03   |
 Paul Rogers
Messages: 152
Registered: July 2009 |
Senior Member |
|
|
Scott,
Thanks for the comments on scripting. Before I answer the specific
questions, I'd like to elaborate on the assumption that both you and I have
made: "most report developers are not Java developers." It has been our
experience that most projects use folks such as SQL developers or "junior
developers" to write reports, and reserve the skilled programmers to develop
the more complex parts of the app. Indeed, a key value proposition of BIRT
is that projects can get high-quality results with BIRT faster than they
would using something like PHP or JSP -- and can do so with team members who
aren't Java experts. This assumption drives the design of the report model
and, as you suggested, the selection of JavaScript.
Indeed, this assumption is parallel to one of the value propositions of JRP:
that Java programmers write application logic in tag libraries; and content
developers create the visual layout in JSP files.
Here I should insert a caveat. While we believe that many reports will be
done by non-Java developers, we also believe that many reports do require
code of some form. Some of that can be scripted in JavaScript, and some
needs "heavy duty" Java developers to create. Even when the code is written
in Java, JavaScript is the "glue" which binds Java to the report.
One other advantage of JavaScript: it allows us to omit a compile step when
running a report: the BIRT Report Engine can directly interpret an XML
report design.
Now, onto the specific questions.
> 1) A BIRT Report developer could use BIRT Script to access functionality
> of
> pre-existing Java Objects that may hold significant business logic that
> you
> would like to access within the report. e.g. A company has developed a set
> of Java objects that expose the company org chart as either a data set
> (for
> use within a report hierarchy) or as a graphical representation. How would
> the BIRT Script interact with those objects?
First, we have to decide on the specific task. Let's take the example above:
exposing an org chart as a data set. Let's assume that the org chart is
represented by a tree, and that the report wants to present this data in the
form of, say, a phone list.
Second, one needs to identify the right element within the design to hold
the "glue" code. In this case, since we're creating a data set, we'd choose
a "scripted data set." (This is an element defined in the not-yet-released
ROM Data specification.)
Third, we work out exactly what the glue code needs to do. The scripted data
set has three methods: open, fetch and close. Let's suppose that the open
method will get a handle to our org chart, perhaps by calling a factory
method exposed in Java. JavaScript has an import statement that creates a
bridge to your Java objects. So, we'd import, say, the factory class and the
"org chart node" class. In open we might say something like the following.
(I've probably got the syntax somewhat wrong, so just focus on the general
idea.)
import com.innovent.yourApp.OrgChartFactory;
import com.innovent.yourApp.OrgChartNode;
var theChart = OrgChartFactory.getChart( );
iter = theChart.iterator( ); // This becomes a property of the data set
instance object
Then, in the fetch method, we'd need to create a row for each org chart
node:
// Done?
if ( ! iter.hasNext( ) ) { return null; }
// Turn the node into a data row
var node = iter.next( );
var row = newDataRow( );
row.name = node.getName( );
row.deptNo = node.getDeptNo( );
row.title = node.getTitle( );
row.phone = node.getPhoneNo( );
// .
return row;
It is necessary to copy the data into a data row so that the Report Engine
can resort it. In our case, the iterator may return the data using a
depth-first traversal, but we want it sorted by name to create a phone list.
You could also create the data row in Java if you prefer.
There is some other boilerplate needed to declare the row schema, but the
above illustrates the key point about calling into Java.
> 2) How Java developers could extend the basic BIRT model through the
> creation of Java objects that are accessed through BIRT script. For
> instance, a company would like to develop a proprietary Stop Light Display
> for use in a management summary report, this display would have a
> significant amount of business logic and display logic that they would
> like
> to implement in Java.
ROM calls this an "extended item". The development team is working on a
specification of exactly how this will happen. Briefly, you start by
creating an extension definition file, something like that created for
plug-ins in Eclipse. In that file you identify the element name, the
properties, and the Java classes to use in the Designer, Report Engine. The
Designer class paints the design-time view of the element using SWT (or can
just return an image.)
The Report Engine has two phases: the Factory (which creates the report) and
the Presentation phase which renders the report to HTML, FO, PDF, etc. The
extension file provides separate classes for each phase. The Factory class
is often optional; even without it the Factory can figure out (from the
property definitions) what data needs to be stored in the report document.
The Presentation class does the bulk of the work. Let's take the simplest
case where the element can be represented by an image. Your stop light
example fits this well. In this case, the Presentation Java class gets two
pieces of information: the element design (or definition) and the element
instance. The element design holds all the properties the user set in the
designer. Perhaps here that includes the color settings, the threshold for
which light to show, etc. The element instance provides the data. Suppose
that the stoplight shows actual sales as a percent of quota. If so, we can
get this percent from the element instance. We then compare this with the
design setting for the threshold, and determine say, that the ratio is 90%,
and so we should show the yellow light.
We then create an image and return it to the Report Engine, which "does the
right thing" to put the image into the HTML file, PDF or whatever.
Notice that, in this second case, no JavaScript is needed. Adding an
extended item is something that a skilled Java developer would do. Once
installed in BIRT, it would be automatically available to all reports as
just a BIRT-defined report item.
That's the high level answer. Please take a look at the extension
specification once it is released and see if it provides the details you'd
need to create such an extension.
As always, please let us know if we're going astray with any of the
assumptions in this response -- now is great time to fix any assumptions
that don't mesh with the BIRT community's experience.
- Paul
Paul Rogers
Actuate Corp.
BIRT PMC
|
|
|
| Re: ROM Feedback: Scripting [message #3019 is a reply to message #1628] |
Fri, 14 January 2005 23:56 |
Eclipse User |
|
|
|
Originally posted by: sschafer.innoventsolutions.com
I have a question that's related, tangentially, to the discussion of the
stoplight image custom component below. I had a situation last year
where I had to do custom charts for a company in Actuate. The charts
involved wierd shapes that were somewhat like ellipses but not exactly.
I accomplished it by using Java to dynamically generate an image and
write it out to a jpg file and then had Actuate load the jpg.
One of the downsides to this approach was that my charts would not zoom
gracefully, like the built-in Actuate charts would. Since my charts
were images, when the user zoomed in, they began to see the pixels and
the lines became jaggy. Actuate's built-in charts, on the other hand,
re-rendered when they were zoomed and thus always looked nice.
I'm wondering if there will be a better way to handle this in BIRT.
Paul Rogers wrote:
> Scott,
>
> Thanks for the comments on scripting. Before I answer the specific
> questions, I'd like to elaborate on the assumption that both you and I have
> made: "most report developers are not Java developers." It has been our
> experience that most projects use folks such as SQL developers or "junior
> developers" to write reports, and reserve the skilled programmers to develop
> the more complex parts of the app. Indeed, a key value proposition of BIRT
> is that projects can get high-quality results with BIRT faster than they
> would using something like PHP or JSP -- and can do so with team members who
> aren't Java experts. This assumption drives the design of the report model
> and, as you suggested, the selection of JavaScript.
>
> Indeed, this assumption is parallel to one of the value propositions of JRP:
> that Java programmers write application logic in tag libraries; and content
> developers create the visual layout in JSP files.
>
> Here I should insert a caveat. While we believe that many reports will be
> done by non-Java developers, we also believe that many reports do require
> code of some form. Some of that can be scripted in JavaScript, and some
> needs "heavy duty" Java developers to create. Even when the code is written
> in Java, JavaScript is the "glue" which binds Java to the report.
>
> One other advantage of JavaScript: it allows us to omit a compile step when
> running a report: the BIRT Report Engine can directly interpret an XML
> report design.
>
> Now, onto the specific questions.
>
>
>>1) A BIRT Report developer could use BIRT Script to access functionality
>>of
>>pre-existing Java Objects that may hold significant business logic that
>>you
>>would like to access within the report. e.g. A company has developed a set
>>of Java objects that expose the company org chart as either a data set
>>(for
>>use within a report hierarchy) or as a graphical representation. How would
>>the BIRT Script interact with those objects?
>
>
> First, we have to decide on the specific task. Let's take the example above:
> exposing an org chart as a data set. Let's assume that the org chart is
> represented by a tree, and that the report wants to present this data in the
> form of, say, a phone list.
>
> Second, one needs to identify the right element within the design to hold
> the "glue" code. In this case, since we're creating a data set, we'd choose
> a "scripted data set." (This is an element defined in the not-yet-released
> ROM Data specification.)
>
> Third, we work out exactly what the glue code needs to do. The scripted data
> set has three methods: open, fetch and close. Let's suppose that the open
> method will get a handle to our org chart, perhaps by calling a factory
> method exposed in Java. JavaScript has an import statement that creates a
> bridge to your Java objects. So, we'd import, say, the factory class and the
> "org chart node" class. In open we might say something like the following.
> (I've probably got the syntax somewhat wrong, so just focus on the general
> idea.)
>
> import com.innovent.yourApp.OrgChartFactory;
> import com.innovent.yourApp.OrgChartNode;
> var theChart = OrgChartFactory.getChart( );
> iter = theChart.iterator( ); // This becomes a property of the data set
> instance object
>
> Then, in the fetch method, we'd need to create a row for each org chart
> node:
>
> // Done?
> if ( ! iter.hasNext( ) ) { return null; }
>
> // Turn the node into a data row
> var node = iter.next( );
> var row = newDataRow( );
> row.name = node.getName( );
> row.deptNo = node.getDeptNo( );
> row.title = node.getTitle( );
> row.phone = node.getPhoneNo( );
> // .
> return row;
>
> It is necessary to copy the data into a data row so that the Report Engine
> can resort it. In our case, the iterator may return the data using a
> depth-first traversal, but we want it sorted by name to create a phone list.
> You could also create the data row in Java if you prefer.
>
> There is some other boilerplate needed to declare the row schema, but the
> above illustrates the key point about calling into Java.
>
>
>>2) How Java developers could extend the basic BIRT model through the
>>creation of Java objects that are accessed through BIRT script. For
>>instance, a company would like to develop a proprietary Stop Light Display
>>for use in a management summary report, this display would have a
>>significant amount of business logic and display logic that they would
>>like
>>to implement in Java.
>
>
> ROM calls this an "extended item". The development team is working on a
> specification of exactly how this will happen. Briefly, you start by
> creating an extension definition file, something like that created for
> plug-ins in Eclipse. In that file you identify the element name, the
> properties, and the Java classes to use in the Designer, Report Engine. The
> Designer class paints the design-time view of the element using SWT (or can
> just return an image.)
>
> The Report Engine has two phases: the Factory (which creates the report) and
> the Presentation phase which renders the report to HTML, FO, PDF, etc. The
> extension file provides separate classes for each phase. The Factory class
> is often optional; even without it the Factory can figure out (from the
> property definitions) what data needs to be stored in the report document.
>
> The Presentation class does the bulk of the work. Let's take the simplest
> case where the element can be represented by an image. Your stop light
> example fits this well. In this case, the Presentation Java class gets two
> pieces of information: the element design (or definition) and the element
> instance. The element design holds all the properties the user set in the
> designer. Perhaps here that includes the color settings, the threshold for
> which light to show, etc. The element instance provides the data. Suppose
> that the stoplight shows actual sales as a percent of quota. If so, we can
> get this percent from the element instance. We then compare this with the
> design setting for the threshold, and determine say, that the ratio is 90%,
> and so we should show the yellow light.
>
> We then create an image and return it to the Report Engine, which "does the
> right thing" to put the image into the HTML file, PDF or whatever.
>
> Notice that, in this second case, no JavaScript is needed. Adding an
> extended item is something that a skilled Java developer would do. Once
> installed in BIRT, it would be automatically available to all reports as
> just a BIRT-defined report item.
>
> That's the high level answer. Please take a look at the extension
> specification once it is released and see if it provides the details you'd
> need to create such an extension.
>
> As always, please let us know if we're going astray with any of the
> assumptions in this response -- now is great time to fix any assumptions
> that don't mesh with the BIRT community's experience.
>
> - Paul
>
> Paul Rogers
> Actuate Corp.
> BIRT PMC
>
>
|
|
|
| Re: ROM Feedback: Scripting [message #4286 is a reply to message #3019] |
Wed, 19 January 2005 06:20 |
Paul Rogers
Messages: 152
Registered: July 2009 |
Senior Member |
|
|
Steve,
Zooming is not a feature in the first release of BIRT, so my answer will be
somewhat speculative.
As you know, in Actuate, you have to generate the image in the Factory, at
the time the report is generated. A single image is used regardless of zoom
factor and output device.
BIRT, however, generates such images in the Presentation Engine when
converting the report for display. Once BIRT supports scaling in a future
release, you can use that scaling information to produce an image of
appropriate size: bigger if the report is zoomed in; smaller if the report
is zoomed out. One can also imagine a future version in which you have the
option of producing an image for the web, or a Scalable Vector Graphic (SVG)
file for PDF.
The Factory and Presentation time behaviors should become clearer once the
development team releases the BIRT extension specification in the coming
weeks.
- Paul
Paul Rogers
BIRT Evangelist
Actuate Corp.
BIRT PMC
"Steve Schafer" <sschafer@innoventsolutions.com> wrote in message
news:cs9m74$cfl$1@www.eclipse.org...
>I have a question that's related, tangentially, to the discussion of the
>stoplight image custom component below. I had a situation last year where
>I had to do custom charts for a company in Actuate. The charts involved
>wierd shapes that were somewhat like ellipses but not exactly. I
>accomplished it by using Java to dynamically generate an image and write it
>out to a jpg file and then had Actuate load the jpg.
>
> One of the downsides to this approach was that my charts would not zoom
> gracefully, like the built-in Actuate charts would. Since my charts were
> images, when the user zoomed in, they began to see the pixels and the
> lines became jaggy. Actuate's built-in charts, on the other hand,
> re-rendered when they were zoomed and thus always looked nice.
>
> I'm wondering if there will be a better way to handle this in BIRT.
>
>
> Paul Rogers wrote:
>> Scott,
>>
>> Thanks for the comments on scripting. Before I answer the specific
>> questions, I'd like to elaborate on the assumption that both you and I
>> have made: "most report developers are not Java developers." It has been
>> our experience that most projects use folks such as SQL developers or
>> "junior developers" to write reports, and reserve the skilled programmers
>> to develop the more complex parts of the app. Indeed, a key value
>> proposition of BIRT is that projects can get high-quality results with
>> BIRT faster than they would using something like PHP or JSP -- and can do
>> so with team members who aren't Java experts. This assumption drives the
>> design of the report model and, as you suggested, the selection of
>> JavaScript.
>>
>> Indeed, this assumption is parallel to one of the value propositions of
>> JRP: that Java programmers write application logic in tag libraries; and
>> content developers create the visual layout in JSP files.
>>
>> Here I should insert a caveat. While we believe that many reports will be
>> done by non-Java developers, we also believe that many reports do require
>> code of some form. Some of that can be scripted in JavaScript, and some
>> needs "heavy duty" Java developers to create. Even when the code is
>> written in Java, JavaScript is the "glue" which binds Java to the report.
>>
>> One other advantage of JavaScript: it allows us to omit a compile step
>> when running a report: the BIRT Report Engine can directly interpret an
>> XML report design.
>>
>> Now, onto the specific questions.
>>
>>
>>>1) A BIRT Report developer could use BIRT Script to access functionality
>>>of
>>>pre-existing Java Objects that may hold significant business logic that
>>>you
>>>would like to access within the report. e.g. A company has developed a
>>>set
>>>of Java objects that expose the company org chart as either a data set
>>>(for
>>>use within a report hierarchy) or as a graphical representation. How
>>>would
>>>the BIRT Script interact with those objects?
>>
>>
>> First, we have to decide on the specific task. Let's take the example
>> above: exposing an org chart as a data set. Let's assume that the org
>> chart is represented by a tree, and that the report wants to present this
>> data in the form of, say, a phone list.
>>
>> Second, one needs to identify the right element within the design to hold
>> the "glue" code. In this case, since we're creating a data set, we'd
>> choose a "scripted data set." (This is an element defined in the
>> not-yet-released ROM Data specification.)
>>
>> Third, we work out exactly what the glue code needs to do. The scripted
>> data set has three methods: open, fetch and close. Let's suppose that the
>> open method will get a handle to our org chart, perhaps by calling a
>> factory method exposed in Java. JavaScript has an import statement that
>> creates a bridge to your Java objects. So, we'd import, say, the factory
>> class and the "org chart node" class. In open we might say something like
>> the following. (I've probably got the syntax somewhat wrong, so just
>> focus on the general idea.)
>>
>> import com.innovent.yourApp.OrgChartFactory;
>> import com.innovent.yourApp.OrgChartNode;
>> var theChart = OrgChartFactory.getChart( );
>> iter = theChart.iterator( ); // This becomes a property of the data
>> set instance object
>>
>> Then, in the fetch method, we'd need to create a row for each org chart
>> node:
>>
>> // Done?
>> if ( ! iter.hasNext( ) ) { return null; }
>>
>> // Turn the node into a data row
>> var node = iter.next( );
>> var row = newDataRow( );
>> row.name = node.getName( );
>> row.deptNo = node.getDeptNo( );
>> row.title = node.getTitle( );
>> row.phone = node.getPhoneNo( );
>> // .
>> return row;
>>
>> It is necessary to copy the data into a data row so that the Report
>> Engine can resort it. In our case, the iterator may return the data using
>> a depth-first traversal, but we want it sorted by name to create a phone
>> list. You could also create the data row in Java if you prefer.
>>
>> There is some other boilerplate needed to declare the row schema, but the
>> above illustrates the key point about calling into Java.
>>
>>
>>>2) How Java developers could extend the basic BIRT model through the
>>>creation of Java objects that are accessed through BIRT script. For
>>>instance, a company would like to develop a proprietary Stop Light
>>>Display
>>>for use in a management summary report, this display would have a
>>>significant amount of business logic and display logic that they would
>>>like
>>>to implement in Java.
>>
>>
>> ROM calls this an "extended item". The development team is working on a
>> specification of exactly how this will happen. Briefly, you start by
>> creating an extension definition file, something like that created for
>> plug-ins in Eclipse. In that file you identify the element name, the
>> properties, and the Java classes to use in the Designer, Report Engine.
>> The Designer class paints the design-time view of the element using SWT
>> (or can just return an image.)
>>
>> The Report Engine has two phases: the Factory (which creates the report)
>> and the Presentation phase which renders the report to HTML, FO, PDF,
>> etc. The extension file provides separate classes for each phase. The
>> Factory class is often optional; even without it the Factory can figure
>> out (from the property definitions) what data needs to be stored in the
>> report document.
>>
>> The Presentation class does the bulk of the work. Let's take the simplest
>> case where the element can be represented by an image. Your stop light
>> example fits this well. In this case, the Presentation Java class gets
>> two pieces of information: the element design (or definition) and the
>> element instance. The element design holds all the properties the user
>> set in the designer. Perhaps here that includes the color settings, the
>> threshold for which light to show, etc. The element instance provides
>> the data. Suppose that the stoplight shows actual sales as a percent of
>> quota. If so, we can get this percent from the element instance. We then
>> compare this with the design setting for the threshold, and determine
>> say, that the ratio is 90%, and so we should show the yellow light.
>>
>> We then create an image and return it to the Report Engine, which "does
>> the right thing" to put the image into the HTML file, PDF or whatever.
>>
>> Notice that, in this second case, no JavaScript is needed. Adding an
>> extended item is something that a skilled Java developer would do. Once
>> installed in BIRT, it would be automatically available to all reports as
>> just a BIRT-defined report item.
>>
>> That's the high level answer. Please take a look at the extension
>> specification once it is released and see if it provides the details
>> you'd need to create such an extension.
>>
>> As always, please let us know if we're going astray with any of the
>> assumptions in this response -- now is great time to fix any assumptions
>> that don't mesh with the BIRT community's experience.
>>
>> - Paul
>>
>> Paul Rogers
>> Actuate Corp.
>> BIRT PMC
|
|
|
Goto Forum:
Current Time: Wed Jul 17 11:31:24 GMT 2024
Powered by FUDForum. Page generated in 0.04220 seconds |
] 
Search
Help
Register
Login
Home
