Re: Some ideas to the report engine...

> Carlos,
> > Well, here you have the idea that i have now to the implementation of
> > the report engine (at the moment I'm only thinking the report viewer
> > part):
> Any reason why working on the client first?  I would suggest hacking
> together an engine that reads a definition file and creates and XML
> output.  Then two different teams can begin work.  One make a client and
> the other making a converter to convert the xml output to diff formats. 
> While the engine continues to be enhanced.  Just an idea.

You have not understand me. When i was talking about the client, I refer
to the part of the report viewer to get and fill the report at the
report server. I think that my english is too poor to explicate it
better. I'm not talking about the front end part, i'm talking about the
report server part to support this front end. You could create an XML
report with "vi", "emacs", "CodeCommander" or "cat", but you only could
process it and fill with data if you have implemented the client part.

> > Well, the IDL that I'll began to implement will be like this:
> > 
> >         A method to open a report (openreport), that will gave us a
> >         Report object.
> >         A method to poblate a report with data from a gda source
> >         (fillreport)
> >         A method to save the report with its data (export as XML, PS,
> >         PDF, HTML, etc.) (savereport)
> >         And a method to close the report (closereport).
> > 
> >         Also it needs all the exceptions to take care about the errors,
> >         etc.
> I would think this is hard to do without the a report (from the server)
> to open.  As well as the rest, but I think we could just be suffering
> some language barrier issues. :)  

I'm talking about the report at the server side, the gnome and X
independent part.

> > 
> > The idea is that with the Report object that we have filled after the
> > fillreport call, we could render it with a gnome-report or kde-report or
> > ncurses-report (or the name it has).
> I am not seeing the client necessarily work like this.  Sounds like too
> much work. :)  I would go for reuse some how.  I think xPDF is free or
> ghostview.  So I would have report server make .ps or .pdf stream/file
> and reuse the code from xPDF/ghostview in a client for viewing.  

Well, this is another posibility, but you are thinking (IMO) in a way
that you only have access to the result report, but if you want take
some flexibility to the application and the user to personalize the
report, you need render at the client side to (for example) indicate a
date range.

> > Or prehaps you want to save it as PS, PDF, HTML, XML (then you have the
> > savereport method). Then, will be the report-server which will export
> > this data as we talk before.
> I would say only difference in save is you push stream to file instead
> of to viewer.

I think that this is another possibility, but with the first i have
talked about before.

> > I think that this is the most simple approachment to this problem,
> > please, suggestions, ideas, questions are welcomed.
> Derek Neighbors
> GNU Enterprise
> derek gnue org

Derek, this week i will have an XML report file as you want :-)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]