Home » Archived » BIRT » Access customXML property from emitter
| Access customXML property from emitter [message #37177] |
Fri, 13 May 2005 15:17  |
Eclipse User |
|
|
|
I'm currently writing a custom emitter to produce XML output.
I'd like to access the customXML property which can be set in the GUI.
Looking at the IReportItemContent interface or the more specific casts
(e.g. ITextContent) used in the emitter classes I can't find a suitable
accessor method.
So I checked with the debugger the data object hidden behind the
interface. But even there I couldn't find a suitable attribute.
Where do I have to look?
By the way: it would be nice to make the designReference attribute
located in the ReportElementContent class accessible by providing a
public accessor method. Even better would be to extend the
IReportItemContent by the same accessor method, too.
Thanks for your help...
|
|
|
| Re: Access customXML property from emitter [message #38307 is a reply to message #37177] |
Wed, 18 May 2005 15:13  |
| Eclipse User |
|
|
|
Hi, Bernd,
You raised a very constructive question. BIRT ROM defines a set of
primitives (report items), such as label, data, text, table, list and
other report items. These primitives are processed in the engine, which
depends on emitters to create report in specific output format.
Current engine has executors, which implement the reporting logic by
bringing data from database, and combine them with report design to
generate another set of primitives, which are "content objects" that you
see. The set of content object primitives are different from the set of
design primitives, as you may have realized that label, data, text and
multi-line data all become a text content object.
Our intention is that emitters only implement presentation logic, while
executors implement reporting logic. What this means is that when emitter
sees a table, it is more of a table we see in word, html, etc. with rows,
columns, as compared to BIRT table with grouping, sorting, etc. defined.
That is, content objects do not faithfully reproduce the original design
semantics, but only the design appearance. We had very preliminary
discussions to open up the executors for extension, and if we do so, you
may see objects that better reflects the original design structure. But we
are not quite sure whether that is a good idea by now.
Back to your question, if only the customXML is needed in the emitter, we
may add it to the content objects; but we view the problem as more
generic: to provide emitter writer access to a data structure that more
faithfully represented the original design. To achieve this, engine needs
to expose certain objects at an earlier stage of its processing, i.e.,
after it combines data in DB with design, but before applying other rules
(such as formatting).
We will take this into account when we move on to the next release. Please
also keep in mind that once we add report document (in R2), things may
change a lot. The report document already has data stored, so the objects
you want to access may be created from the report document (still by the
engine, though).
Do you mind sharing with us a couple of reports, and state your
requirements in this case, so that when we plan for R2, we are more
concious of the problems you want to address? Thanks.
Stanley
BIRT Engine
|
|
|
| Re: Access customXML property from emitter [message #38756 is a reply to message #38307] |
Thu, 19 May 2005 12:20 |
| Eclipse User |
|
|
|
Hello Stanley,
yes, I also see that it makes sense to distinguish between design-time
elements and the content elements resulting from processing these
design-time elements with the engine.
Nevertheless, I think that it would make sense to allow all stages of
the report production (engine, executor, emitter) (read-only) access to
the design-time elements.
The fact that the implementation (base class ReportElementContent) of
the content elements (IReportItemContent) already has a member
"designReference" which holds a reference to the design-time element
used to create that content element indicates that at least some of the
design-time data is needed up to the very end of the report production
process.
Parts of the design-time elements' data aleady have been made visible
using accessor methods which pass through selective data from the
design-time element to the IReportItemContent and derived interfaces
(e.g. getName()).
This becomes even more pronounced if you look at the design-time style
definitions which _must_ be passed to the emitter stage to produce the
equivalent visual styles.
So the emitter needs to know the design-time descisions made by the
user, don't you concur?
I think it would be easiest to make all the properties the user can set
in the designer property editor visible to all report production stages.
So my proposed change would be
a) make the designReference element accessible via the
IReportItemContent interface.
b) introduce a base interface/class for the design-time elements
c) maybe add specialized, derived interfaces for specific design-time
elements
d) make the currently missing design-time properties (like customXML)
accessible via this design-time element interface.
You asked why do I need more design-time property access in my specific
case?
My original thought was that producing custom XML output shouldn't be so
much different from producing styled HTML output.
I thought to use the report designer to define only the _structure_ of
the output data, not necessarily the _appearance_ of the data (alas this
would also be possible applying the design-time styles as CSS styles to
the generated XML tags).
Sample output:
<?xml version="1.0" ?>
<report>
<picture href="some-url-from-db"/>
<structured-data-from-db-query-foo>
<row>
<name>Some Name</name>
<street>Some Street</street>
</row>
</structured-data-from-db-query-foo>
<aid:table xmlns:aid="http://ns.adobe.com/AdobeInDesign/3.0/">
<aid:thead>
<aid:tr>
<aid:td>Durchmesser [mm]</aid:td>
<aid:td>Segmentbreite [mm]</aid:td>
<aid:td>Segmenthöhe [mm]</aid:td>
<aid:td>Preis [EUR]</aid:td>
</aid:tr>
</aid:thead>
<aid:tbody>
<aid:tr>
<aid:td>115</aid:td>
<aid:td>2,4</aid:td>
<aid:td>7</aid:td>
<aid:td>36,00</aid:td>
</aid:tr>
</aid:tbody>
</aid:table>
</report>
You see table structures using different tag names than table, row, td,
etc and single "data" or "text" elements using an integrated "label",
the tag name (which could result from the design-time name property).
Also, you see "data" or "text" elements represented as tags with an
attribute that is filled with data (that might be more complicated to
specify during report design-time).
The Rolls-Royce solution:
The tag names and other XML "output-styles/mappings" should configurable
as design-time style properties.
E.g. For a table design-time element, the user should be able to denote
a style or mapping which XML tags and attributes are to be produced by
the XML emitter.
Alas this kind of taints the design-time environment with emitter
specifics...
One could keep the impact to the desin-time environment limited by
introducing an emitter specific style extension.
This extension could provide a property tree wich would be made visible
in the designer style property editor, like this
"XML emitter styles"
"tag name"
"attributes"
"name" - "value"
It gets more complicated if the XML tag names should be filled with
data-source data. I guess that would be the moment a specific
design-time report element might be necessary.
The VW-Beetle solution:
The emitter accesses the customXML design-time property which is filled
by the user with a predefined XML dialect describing the desired XML
output style (tag name, namespace, attributes).
This would be enough for my current needs, but I can't access the
customXML, sniff...
Alas, as far as I can see, even customXML won't be accessible for me in
the near future. Maybe I should concentrate on finding another solution,
like XSLT postprocessing or using velocity to get what I need...
Thanks for your help!
Bernd
|
|
|
Goto Forum:
Current Time: Sat Jun 07 12:21:43 EDT 2025
Powered by FUDForum. Page generated in 0.02564 seconds |
Home