my general impression is that the reports-subreports hierarchy is too high level a metaphor for convenience and, especially with sufficiently suboptimal preview interface, hard to work with.
I personally would have liked it to be more of a “I load data from database and add rows one after the other to table objects on the page, using styling info input using a separate editor”. I.e. closer to the web programming in a styled page type of work. Naturally, with debugging being then as easy as just put some logging code into the code that does the printing.
My main environment is DevExpress Reports, and I am pretty sure that something like that could be implemented there. For now I am just stuck with the legacy code that seems to emulate the Crystal Reports way of doing things, I guess.
Has there been discussion along these lines in the programmer community? Does everybody considers the reports/subreports setup normal and easy to work with or is there in fact a community of dissidents who would prefer a different model, whether what I have briefly described above or some entirely different competing model that I should read up on?
Reports/sub-reports encompasses a lot of ground. Are you in some sort of environment where you layout the report and the sub-report separately or something and that is the issue?
first of all, yes, I am forced to layout subreports in separate file. A single report ends up being a folder worth of code files. It takes some effort to figure out what does any of these files have to do with in the actual output.
Second, let me clarify my thought. What I especially don’t like is the declarative, SQL-based nature of reports printing. I.e. there is an automated mapping from SQL output to the tables on the page, or the nested tables of tables and so on. High level abstraction turns into high complexity when maintaining it. I have seen cases where I did something wrong and (and no, I don’t believe in yesterday…) all of a sudden it would print hundreds of empty pages. And I was, like, wtf?,and it was, like, your error now be under da hood! Mwahaha, dude…
Like I said above, I think it would be better if the logic involved were procedural - truly procedural and not of the Crystal Reports script for formatting kind of afterthought.
To reiterate my question, have other people voiced similar concerns in “Visual Basic vs Lisp” type of flame wars or else in reasoned research papers? Or is everybody strongly united in support of the declarative reports generation model?
I’m not sure exactly what you’re asking, but I suspect that were the opposite paradigm in use, your complaints would be along the lines of
“Dude, what’s up with this report code crap? I mean, why do I have to keep retyping the name of every single variable, and good lord am I tired of typing column locations for each one. I’d have no clue what the output would look like until I ran the damn thing. Then all of a sudden, it would print gibberish, and it was like ‘ha ha somewhere you dropped a comma between the column and row dummy; now you got to go find it in all that procedural crap’. I mean, we’ve got all these fancy GUI interfaces and Pagemaker and stuff. Wouldn’t it be way quicker if I could just start with a blank report and drag stuff around to where I want it, instead of having to tell the stupid computer every single stupid little thing?”
do I understand correctly that I am the first guy the readers of this thread have encountered who bitches about reports being transparently generated from query?
I am not sure how natural or unnatural such a hypothesis would be. There are plenty of “Crystal Reports sucks” pages online, but I don’t think that specific criticism of the paradigm is common. Which could mean that I am a lazy researcher, or that the paradigm rocks, or that people don’t bother thinking of high level alternatives and just bitch about minor peeves within the paradigm (much like Ford’s hypothetical customers who would have liked faster horses and not think of an alternative vehicle paradigm).
If you are dealing with files in a folder and you need to figure out what they have to do with the output then you are using a more primitive tool than most of us are probably used to.
What kind of tool are you using that uses declarative mapping?
Most power-user report writing tools have “topic” specific data models (a subset of the enterprise database) and a graphical layout where you drag and drop fields.
Lower level report writing environments like Reporting Services do allow for custom SQL, but still have a graphical layout.
Alternatively, there are OLAP tools which allow you to drop in rows and columns from a completely denormalized view of the database. This isn’t really “report writing” because you can’t do formatting, it just rows and columns.
It might be the specific environment you are using, it doesn’t sound like it maps very well to most current report writing environments.
No, I do have a graphical environment where I put the fields, tables and subreports in place. Maybe it just isn’t as powerful a visual designer than Crystal Reports.
The SQL I mention has to do with the environment allowing me to run SQL from my code. By contrast, AFAIU Crystal Reports requires us to have the SQL inside a view or stored procedure. Or maybe just inside the Crystal Reports app itself - I am not sure, but basically with DevExpress you can just feed a dataset to the reporting system. You could even have your code create or at least mess with the data before feeding it to the report, which is closer to the alternate paradigm I am discussing.
So yeah, DevExpress Reports does seem to give me the ability to write code in this style - it seems to support both the paradigms. It even allows adding rows, tables etc programmatically on the fly, which inter alia means that anybody could build his own “new and improved” reports solution as a wrapper around DevExpress. Hey, what a thought!
But yeah, the guys who wrote the legacy code apparently thought that “transparent” and “least amount of code in the file” is more important than “maintainable” and “least headache for me”.
and yes, on second thought I do agree with RaftPeople that me having to deal with multiple subreports as with multiple code files is in essence the fault of the visual designer. Crystal Reports, by contrast, lets you work with all subreports on a single design page.
There is nobody stopping DevExpress (or, for that matter, any other entity, myself included) from making a better visual editor for the platform, but so far nobody has bothered to do so.
Fortunately my experience with DevExpress was more positive and a lot less painful than that guy’s claimed experience with Crystal Reports. Or maybe he just had to do more complex stuff than what I am used to doing.
