Java Objects

[Kevin Yeung <ke...@pacific.net.hk>]

Hi all

I was wondering if there is work/plan going on to write Java objects for
FOP? For example, we can write a class for block that corresponds to
fo:block; one for fo:table, etc. Then, programmers can instantiate these
objects and build a report programmatically.

I am actually going to do that. Does anyone know of any deficiency in this
approach?

Thanks & regards
Kevin

RE: Java Objects

[Chris John <ch...@viridian.com.au>]

I think it is a good idea. You might be able to save some time if you look
at the source to Pajes (www.pajes.org) as this does the same thing for HTML.

Chris

-----Original Message-----
From: Kevin Yeung [mailto:keviny@pacific.net.hk]
Sent: Monday, 1 July 2002 11:37 AM
To: fop-user@xml.apache.org
Subject: Java Objects


Hi all

I was wondering if there is work/plan going on to write Java objects for
FOP? For example, we can write a class for block that corresponds to
fo:block; one for fo:table, etc. Then, programmers can instantiate these
objects and build a report programmatically.

I am actually going to do that. Does anyone know of any deficiency in this
approach?

Thanks & regards
Kevin

Re: Java Objects

[Oleg Tkachenko <ol...@multiconn.com>]

Kevin Yeung wrote:

> Thanks for your reply. The reason I want to do this is we need a
> server-side reporting component. We want to be able to write SQL, fetch
> records from the database and have a printable PDF report of these
> records. We want to then generate the XML at runtime. The way I can think
> of is to have a block class, a table class, and so on. I instantiate these
> objects, passing them the data from the RDBMS.
I believe this way you'll get strong coupling between your data and 
presentation and next time in order to change report style you'll have to 
modify again this code module instead of just applying another xslt 
stylesheet. I believe data must stay to be pure data if you want to get all 
virtues of xsl.

> Then, just call toString()
> or something and have the XML automatically generated, which is passed to
> FOP to get the PDF.
I'd implement it as, errrr, toXMLAsSAXEvents(), there is no need for string here.

-- 
Oleg Tkachenko
Multiconn International Ltd, Israel

RE: Java Objects

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

OK, I see what you're getting at. So this is not really anything to do with
FOP per se; in fact we could be talking about any XSL formatter.

I think you're creating an unnatural model by describing the _FOs_ as Java
objects. Let FOP take care of that internally. A block for example, is just
a multi-line chunk of text - there are a number of real data in your DB that
probably need to be displayed that way. In one case it could be a field in a
row of a DB table, but in another case it might be a descriptive note in the
report. Both become FO blocks.

I think you are better off modelling the _data_ in your DB. Let's say for
example that you have an overall class called Report - this knows how to
create FO XML for the page-masters and region-masters. Maybe Report has a
Vector that contains a couple of other objects - one is called
WeeklySalesTable and the other is YearToDateSalesTable. Report knows to call
toXml() on each of these, in order, and wraps them in approprate XML
besides - page-sequence(s), static-contents, and flow.

Both WeeklySalesTable and YearToDateSalesTable understand how to generate
XML for FO tables, and can retrieve the DB data for table cells (maybe
through a data access object or DAO that actually does the SQL). There could
be more granularity - each row might well be a value object (that loads from
the DB using the DAO) called SalesLineItem or something, that knows how to
produce the appropriate FO XML (as in a fo:table-row and contents).

So I don't think your approach is bad but I just think you're modelling the
wrong things.

Hope this helps.

Arved

> -----Original Message-----
> From: Kevin Yeung [mailto:keviny@pacific.net.hk]
> Sent: June 30, 2002 11:04 PM
> To: fop-user@xml.apache.org
> Subject: RE: Java Objects
>
>
> Hi Arved
>
> Thanks for your reply. The reason I want to do this is we need a
> server-side reporting component. We want to be able to write SQL, fetch
> records from the database and have a printable PDF report of these
> records. We want to then generate the XML at runtime. The way I can think
> of is to have a block class, a table class, and so on. I instantiate these
> objects, passing them the data from the RDBMS. Then, just call toString()
> or something and have the XML automatically generated, which is passed to
> FOP to get the PDF.
>
> Or is there a way out of this? :)
>
> Thanks & regards
> Kevin
>
> On Sun, 30 Jun 2002, Arved Sandstrom wrote:
>
> > Date: Sun, 30 Jun 2002 22:53:25 -0300 From: Arved Sandstrom
> > <Ar...@chebucto.ns.ca> Reply-To: fop-user@xml.apache.org To:
> > fop-user@xml.apache.org Subject: RE: Java Objects
> >
> > > -----Original Message-----
> > > From: Kevin Yeung [mailto:keviny@pacific.net.hk]
> > > Sent: June 30, 2002 10:37 PM
> > > To: fop-user@xml.apache.org
> > > Subject: Java Objects
> > >
> > > I was wondering if there is work/plan going on to write Java
> objects for
> > > FOP? For example, we can write a class for block that corresponds to
> > > fo:block; one for fo:table, etc. Then, programmers can
> instantiate these
> > > objects and build a report programmatically.
> > >
> > > I am actually going to do that. Does anyone know of any
> deficiency in this
> > > approach?
> >
> > No deficiency, per se. :-) Basically, package org.apache.fop.fo.flow and
> > org.apache.fop.fo.pagination already have all of these classes
> that you are
> > talking about. :-)
> >
> > And then there are hundreds of other classes that actually make
> layout work.
> >
> > What you are really saying, if I understand you correctly, is
> that you want
> > to bypass the XML stage, and start with an object tree. That's certainly
> > something you can try.
> >
> > But don't re-implement all the FO and property classes. :-)
> >
> > Just out of curiosity, why do you want to do this?
> >
> > Regards,
> > Arved Sandstrom
> >
> >
> >
>
> --
> K
>

RE: Java Objects

[Kevin Yeung <ke...@pacific.net.hk>]

Hi Arved

Thanks for your reply. The reason I want to do this is we need a
server-side reporting component. We want to be able to write SQL, fetch
records from the database and have a printable PDF report of these
records. We want to then generate the XML at runtime. The way I can think
of is to have a block class, a table class, and so on. I instantiate these
objects, passing them the data from the RDBMS. Then, just call toString()
or something and have the XML automatically generated, which is passed to
FOP to get the PDF.

Or is there a way out of this? :)

Thanks & regards
Kevin

On Sun, 30 Jun 2002, Arved Sandstrom wrote:

> Date: Sun, 30 Jun 2002 22:53:25 -0300 From: Arved Sandstrom
> <Ar...@chebucto.ns.ca> Reply-To: fop-user@xml.apache.org To:
> fop-user@xml.apache.org Subject: RE: Java Objects
> 
> > -----Original Message-----
> > From: Kevin Yeung [mailto:keviny@pacific.net.hk]
> > Sent: June 30, 2002 10:37 PM
> > To: fop-user@xml.apache.org
> > Subject: Java Objects
> >
> > I was wondering if there is work/plan going on to write Java objects for
> > FOP? For example, we can write a class for block that corresponds to
> > fo:block; one for fo:table, etc. Then, programmers can instantiate these
> > objects and build a report programmatically.
> >
> > I am actually going to do that. Does anyone know of any deficiency in this
> > approach?
> 
> No deficiency, per se. :-) Basically, package org.apache.fop.fo.flow and
> org.apache.fop.fo.pagination already have all of these classes that you are
> talking about. :-)
> 
> And then there are hundreds of other classes that actually make layout work.
> 
> What you are really saying, if I understand you correctly, is that you want
> to bypass the XML stage, and start with an object tree. That's certainly
> something you can try.
> 
> But don't re-implement all the FO and property classes. :-)
> 
> Just out of curiosity, why do you want to do this?
> 
> Regards,
> Arved Sandstrom
> 
> 
> 

--
K

RE: Java Objects

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

> -----Original Message-----
> From: Kevin Yeung [mailto:keviny@pacific.net.hk]
> Sent: June 30, 2002 10:37 PM
> To: fop-user@xml.apache.org
> Subject: Java Objects
>
> I was wondering if there is work/plan going on to write Java objects for
> FOP? For example, we can write a class for block that corresponds to
> fo:block; one for fo:table, etc. Then, programmers can instantiate these
> objects and build a report programmatically.
>
> I am actually going to do that. Does anyone know of any deficiency in this
> approach?

No deficiency, per se. :-) Basically, package org.apache.fop.fo.flow and
org.apache.fop.fo.pagination already have all of these classes that you are
talking about. :-)

And then there are hundreds of other classes that actually make layout work.

What you are really saying, if I understand you correctly, is that you want
to bypass the XML stage, and start with an object tree. That's certainly
something you can try.

But don't re-implement all the FO and property classes. :-)

Just out of curiosity, why do you want to do this?

Regards,
Arved Sandstrom