The interesting point about the 'excess power' was in areas that didn't have power wired in. Rather than installing a generator in the cabin, you plug in your car when you get there.
In rural areas without power, as long as you have a supply of gas that's not too distant, you could use your new vehicle as transport and power, both.
These are usually called 'Coverage' or 'Test Coverage' tools. They do certain exist, although I hate to say that I haven't used one myself yet, so I can't comment on their efficacy.
But just think how compressible that is. You'll be able to compress your.xml at extremely high ratios, way more than you can compress, say, an MP3 or an Ogg Vorbis file.;)
I am certainly interested in making use of J2EE because it's an environment I enjoy working in; there are also some other solid reasons for considering it for this project.
That said, I'm mostly looking for a good solution for the problem, and reporting is only one facet of that, and I also have to consider the core competencies of some of the people who may or may not be involved in the project.
Given the general MS bias of the most direct client (and the web requirement that has nothing to do with the reporting side), ASP is also a strong candidate.
Ultimately, however, it doesn't look as if I'm going to have to make architectural choices based on the reporting. There's been a number of interesting comments on PDF generation (which was a consideration, but I'll have to do some performance testing) and recommendations for more report generation software than I have a reasonable chance of reviewing before I have to make a decision. Most of these will operate on more than one platform and more than one development environment.
Does that remove some of your fear about the way I phrased the question?
Thanks again for all the commentary, even those of you who provided some useful information while implying that I was either lazy or mentally challenged. The breadth of responses gives me exactly the kind of information I was hoping for, far more detailed than a simple examination of Crystal Reports and a PDF library. Personal experiences with products, commentary on the pros and cons, a great deal of it was useful.
As for those people who felt I should have 'done my research', this one of the avenues in which I was doing just that, and given the level of response, it was worth a few flames and trolls to get a mass of cogent thoughts and recommendations.
My client prints reports to send to their client, or to do mass mailings to their client's clients. They feel these reports are necessary, and their client (or their client's clients) will not have access to the app in this phase.
Frankly, I'd prefer no printed reports at all, but it's not up to me to determine what the client feels they need.
Acutate was actually topping my list on the J2EE side (based on some threads on the Java Dev Connection), but I was hoping for opinions based on experience, as well as solutions outside of the J2EE space, and the kind of commentary that a forum like this can generate. There's a lot of interesting commentary in this thread already.
No, I dn't think you can control page breaks in HTML. Besides, if the reports are long, printing them through the web browser isn't ideal. I'd be looking at integrating with reporting software or, alternately, doing something like PDF generation.
Slashdot Mirror
The interesting point about the 'excess power' was in areas that didn't have power wired in. Rather than installing a generator in the cabin, you plug in your car when you get there.
In rural areas without power, as long as you have a supply of gas that's not too distant, you could use your new vehicle as transport and power, both.
These are usually called 'Coverage' or 'Test Coverage' tools. They do certain exist, although I hate to say that I haven't used one myself yet, so I can't comment on their efficacy.
But just think how compressible that is. You'll be able to compress your .xml at extremely high ratios, way more than you can compress, say, an MP3 or an Ogg Vorbis file. ;)
I am certainly interested in making use of J2EE because it's an environment I enjoy working in; there are also some other solid reasons for considering it for this project.
That said, I'm mostly looking for a good solution for the problem, and reporting is only one facet of that, and I also have to consider the core competencies of some of the people who may or may not be involved in the project.
Given the general MS bias of the most direct client (and the web requirement that has nothing to do with the reporting side), ASP is also a strong candidate.
Ultimately, however, it doesn't look as if I'm going to have to make architectural choices based on the reporting. There's been a number of interesting comments on PDF generation (which was a consideration, but I'll have to do some performance testing) and recommendations for more report generation software than I have a reasonable chance of reviewing before I have to make a decision. Most of these will operate on more than one platform and more than one development environment.
Does that remove some of your fear about the way I phrased the question?
As for those people who felt I should have 'done my research', this one of the avenues in which I was doing just that, and given the level of response, it was worth a few flames and trolls to get a mass of cogent thoughts and recommendations.
My client prints reports to send to their client, or to do mass mailings to their client's clients. They feel these reports are necessary, and their client (or their client's clients) will not have access to the app in this phase. Frankly, I'd prefer no printed reports at all, but it's not up to me to determine what the client feels they need.
Acutate was actually topping my list on the J2EE side (based on some threads on the Java Dev Connection), but I was hoping for opinions based on experience, as well as solutions outside of the J2EE space, and the kind of commentary that a forum like this can generate. There's a lot of interesting commentary in this thread already.
No, I dn't think you can control page breaks in HTML. Besides, if the reports are long, printing them through the web browser isn't ideal. I'd be looking at integrating with reporting software or, alternately, doing something like PDF generation.