Do you also support/plan to support printing reports for data generated inside application ?
For example for me, getting data from database is not a problem - I have to do it anyway. Things printed are not simply results of some sql mangling - they need some/a lot of of munching inside application. So what I'm looking for is ability to feed my own data to reports, at the same time having possibility to reuse your layout engine/printing utils etc.
Second question is how much control over layout sheets do you plan to implement from inside program. I'm talking about stuff like hiding some columns, changing fonts and colors etc. I suppose it is non-critical, as I can always work directly with xml through one of java apis, but having nice report control API would be possibly nicer.
I'm asking this questions, because my company will be looking for some report package with source available. We have plans to roll out our own stuff if we will not find anything usable (and we have to be able to modify source, as we had bad problems with previous report package - which could be trivially fixed, given access to source...). I suppose that most (if not all) of changes we will make would go back here. But as I say - our main interest is in layout engine, not database access helpers.
I've downloaded source now and will look into it :)
I have not planned to support printing reports for data generated outside of DataVision. I have thought about writing a layer that would let DataVision read a data file (for example, comma-separated or XML) instead of run a SQL statement, but that is low on my list.
That said, take a look at the jimm.datavision.Layout class; you may be able to rip it out and use it.
Control over layouts will be at runtime, at both the field and the section level. Sections will have "suppression procedures": boolean expressions you can write that are evaluated at runtime to show or hide a section. Same for fields. This is similar to what Crystal Reports has.
In the far future, you will probably be able to control font color and other attributes (say, red for negative numbers) similarly.
I'm glad you're looking at the source. Any comments would be appreciated.
Just an idea and probably not very hard to implement. Maybe I could do it when I upgrade my stone-aged P1200Mhx/64MB machine to a modern age.
Let's implement InMemoryJdbcDriver, which does nothing but provide a read access to memory structure.
Read access should do fine in DataVision and other read-only scenarios, right???
What jdbc column datatypes DataVision supports atm?
What metadata methods should be provided?
(resultset, databasemetadata requirements)
How is SUM/AVG and other aggregate functions performed in DataVision reporting engine. It does not require such aggregates supported in an underlying database engine, but loops and calculates own summaries?
Should jdbc driver support transactions, previous/next row iteration?
-> is next row iterarion ok, without a previous steps?
Users could load data into InMemoryJdbcDriver before "connecting to a database".
Additional myDataResolver implements a simple interface, which should provide few methods:
getString(int), getLong(int), getBoolean("colName")
Implementing this interface would provide a basic column getters, so that users could use existing datamodels here. Resolver is only a bridge between DataVision and xyz-datamodels.
metaDataDescription should provide column types, lenght, etc... information to be used on each table. Or should driver resolve this info directly from xml,cvs datafiles..hmm...
There are restrictions:
Users cannot link tables, only sql formula supported is "Select * From tTableA".
No filtering provided such as "where col='ABC'"
xml/csv/txt file must be fully constructed prior loading it to a memory driver.
Is that too wild idea?
My machine is PentiumI 200Mhz/64MB, not P1200Mhz as previous msg might say.
I want to abstract out all data access so we can have "pluggable" data sources just like we have pluggable layout engines.
I need to think about what interface will be required, and need to document that.
Formulas, sums, etc. are all calculated by DataVision as it loops through the data. It does not rely on the database.
DataVision *does* use previous() and last(). It is possible to rewrite DataVision so that it does not use these, but that will be a bit of work. Basically, I will have to cache the previous row of data.
previous/next are quite database specific. For other sources it could be possible to require ALL data to be available at once and create small wrapper.
Anyway, I would suggest leaving core as it is (using previous/next logic, just not on ResultSet, but some interface) and provide some wrappers around different datasets. In case of ResultSet it could call underlying methods directly, in case of explicit data in form of array/table, wrapper could remember last row accessed and just update internal index.
For application-provided datasets, I think it will be best to just require all of stuff at once. Maybe with 100 page reports it would make a difference, but for smaller cases it is easiest for app to do this and helps to avoid unneeded synchronization/messing with threads.
Yep, having a DataVisionModelInterface would give a flexibility to provide an in-application data for reporting engine. This would eliminate the need of java.sql package if one is not required.
..I see the thread on this subject is a bit old....Mr. Menard - was this feature added between now and then (reporting from non-db data?).
I use mpxj to suck MS Project data into an array, and I would like to use datavision to report on it.
Great product, thanks for all your effort.
DataVision can read from char-separated text files (comma- or tab-separated csv files, for example). See the User's Manual for details and the charsep* files in the examples directory.