Re: New gda-repor.[ch] and DTD

[Rodrigo Moya <rodrigo linuxave net>]

> > What I would do is what I said some time ago. I would define a set of
> > signals for the Gda_Report object to be emitted when the report is being
> > generated. That is, a "begin_doc", "add_header"... signals. It wouldn't
> > be a bad idea to save as well the report output to a XML file.
> 
> This is MUCH closer to what GNUe is looking to do.  I still dont get
> this groups obsession w/ DTD's.  DTD's are HORRIBLE documentation and
> have little value when you are first starting an XML based tool. (IMHO).
> 
I agree with you on this. Even knowing that I'll be flamed on this, I
must confess that I haven't done the DTD for the database import/export
stuff. I've started coding, and, as soon as I'm confident with the code,
I'll add, probably, the DTD.

> A glaring example is Mozilla XUL framework.  It can do quite a bit and
> they still have no DTD.  When spec changes daily trying to keep up with
> a DTD is just a reason to use CVS. :)  I would rather see someone
> document the ideas behind the layouts than some cryptic DTD, but oh
> well, I guess why complain if someone is willing to do something. :)
>  
> > These signals would be very useful for frontends to the report, such as
> > the GNOME specific part we talked about.
> 
> I am not sure I agree here in that I dont think the front end shoudl
> have to deal with anything except a finished report, though I could be
> convinced of some other scenarios. ;-)
> 
Well, I think it's good idea in that thus a UI-specific tool can build
the report as it is executed. As I said in a previous mail, I think the
report engine SHOULD generate the output of the report, but also have
the option of not generating it, and thus leaving this responsibility to
the top-level tool (the GnomeDbReport).

But, really, all I said about the report engine are just thought, so
don't take it as if it were the bible, and the thing to do.

cheers