Re: [Babeldoc-devel] Temp branch

[Michael A. <mic...@ze...>]

Hi, Dejan,

Sorry for taking so long with this.  It got forgotten in the mail folder
for a while.

The new pipeline stage that I'm building takes as input the document
produced by the SqlQuery stage, as well as a report definition string
(XML), and some other miscellaneous attributes, and uses the
jfreereports library to produce a report as the output document.  The
report can be in HTML, pdf, CSV or Excel format, to being with.  Not
sure what else jfreereports can do.

Any ideas to fit in with that, and I'm all ears.  

Jfreereports expects the report definition in XML format, and it expects
the data in the form of a TableModel.  So, I'm busy writing an
implementation of an AbstractTableModel that can use the xml from
SqlQuery as input.
I figured the report definitions, which are in XML, could be added as
attributes to the data document.

Once that's finished, I want to do the same for jfreechart, which would
then produce, surprise, surprise, charts and graphs of input data.  Same
concept, slightly different output.  Both libraries are available from
www.jfree.org, if you want to have a look at their features and stuff.

Cheers...


MikeA



On Thu, 2003-11-13 at 10:06, Dejan Krsmanovic wrote:
> > I think that we should probably look at guidelines for 1.3, and try to
> > do as much as possible without breaking anything.  I'm happy to move the
> > jfreereports stuff into a separate project, even for 1.3.  It's not in
> > 1.2, so there are no issues with compatibility.
> >
> > In order to set the guidelines, a few questions: what constitutes a core
> > module (i.e.: one which goes into com.babeldoc.core.pipeline or
> > com.babeldoc.scanner)?  Or a secondary (i.e.: it goes into e.g.:
> > com.babeldoc.sql.*), or a peripheral module (i.e.: into it's own CVS
> > project and separate jar files)
> 
> Well these are the issues we should talk about. I am not very satisfied with
> current module organization. IMO, in core module there should be classes
> needed by other modules. For example, I would put scanner classes into core
> module. However, I would exclude all classes (scaner workers, pipeline
> stages, journal implementations) that need some additional jars or that are
> not used very often.
> All other modules should be developed, maintained and downloaded separately.
> 
> 
> > As far as the mechanics go, what about having a "contrib" top-level
> > project, into which any developer can place any experimental code.
> > Postgres do this, and it seems to work quite well.  When something in
> > contrib is considered to have matured enough, and be demanded enough, to
> > be in the core system, it's migrated from contrib into the main project.
> >
> > Thoughts...
> 
> I agree. I would even create this as separate CVS project so we can grant
> CVS commit rights to everyone who wants.
> 
> By the way, what exactly will do your new pipeline stage (jfreereport)?
> 
> Dejan
> 
> >
> > MikeA
> >
> > PS: I added a stack of directories before branching, I'm not sure if
> > they appear on the HEAD now.  Anybody getting the new directories when
> > they "cvs update"?
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel