最大限度地减少实施可打印报告的痛苦
在报告方面，如何最大程度地减少开发过程中的痛苦？
对于 Web 框架，有一种非常简单的方法来生成内容并进行图形设计；内容通过 HTML 语义表示，设计通过 CSS 单独指定。浏览器与它们呈现输出的方式相当一致（并且不一致是众所周知的并且可以计划）。甚至还有 WYSIWYG 编辑器来帮助不太懂 CSS 的图形设计师。
但我们该如何处理印刷内容呢？
在一家公司，我创建了一个流程，其工作方式如下：脚本通过 XML 生成语义表示。 XML 通过 XSLT 传递以生成 XML-FO 文档。然后，它被传递给另一个工具（Apache FOP，我相信）来生成 PDF。这对该公司来说效果很好。
然而，在这家公司，输出外观对管理层很重要，而且我们有一名图形设计师。目前，我们正在使用报告工具（Developer Express 的 XtraReports，版本 8.1）。这还不错；它输出为多种格式，具有所见即所得设计器，报告通过 C# 类实现，并且支持数据绑定到数据集（不幸的是，不是 POCO 的）。然而，这种设置有一些主要的痛点：
- 报告框架对于如何布局和分组报告区域有很大的限制
- 可呈现的元素，尤其是图表，缺乏我们需要微调和实现我们的外观的功能。模型。
- 没有像我们通过 CSS 获得的那样在报告之间共享样式和布局的好方法。
- 可重用部件的良好可组合性很难实现。所以我们最终得到了大量的副本和内容。粘贴功能的继承；每当我们需要对所有报告进行彻底更改时，这都是个坏消息。
现在，也许有一些强大的框架可以消除报告框架的痛苦，但我认为它们都有自己的弱点。您是否有一个适合您并减少报告固有痛点的框架或流程？
How do you minimize the pain in your development process when it comes to reporting?
For web frameworks, there is a pretty straightforward way to both produce content as well as graphically design it; content is represented semantically through HTML, and the design is separately specified through CSS. And browsers are fairly consistent with how they render the output (and the inconsistencies are well-known and can be planned for). There are even WYSIWYG editors to help out less-CSS-savvy graphical designers.
But what do we do about print content?
At one company, I created a process that worked like this: A script generated a semantic representation through XML. The XML was passed through XSLT to generate an XML-FO document. Then, this was passed to another tool (Apache FOP, I believe) to generate a PDF. This worked well for that company.
At this company, however, output appearance matters to management, and we have a graphical designer. Currently, we are using a reporting tool (XtraReports from Developer Express, version 8.1). It isn't bad; it outputs to a variety of formats, has a WYSIWYG designer, reports are implemented through C# classes, and it supports data binding to data sets (unfortunately, not POCO's). However, we have some major pain points with this setup:
- The reporting framework has major limitations on how you can lay out and group your reporting bands
- Presentable elements, especially charts, lack the capabilities we need to fine-tune and achieve the look of our mock-ups.
- There is no good way to share styles and layout among reports akin to what we can get through CSS.
- Good composability of reusable parts is very hard to implement. So we end up with a lot of copy & paste inheritance of functionality; this is bad news whenever we need to make sweeping changes across all reports.
Now, maybe there's some kick-ass framework out there that can eliminate the pains of reporting frameworks, but I assume that they all have their weaknesses. Do you have a framework or process that works well for you and reduces the pain points inherent in reporting?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Prince XML 是一个非常酷的工具，它允许您使用带有 CSS 样式的 HTML 或 XML（包括 CSS 分页媒体 用于打印）并从中生成 PDF。
Prince XML is a really cool tool which allows you to use HTML or XML styled with CSS (including CSS paged media for printing) and generate PDFs from it.
选项#1：Adobe Acrobat 非常好用。您可以设计支持表单的 PDF，然后使用 PDFSharp 之类的内容来操作 PDF 文档。您可以创建模板 PDF，并将生成的内容转储到其中。我以前曾经这样做过并且非常成功。我也很好地使用了 POCO 对象。
选项 #2：您可以开始创建 XPS 文档，无论如何它都是基于 XML 的。如有必要，它们可以轻松转换为 PDF。
选择#3：逃命。（可能不是一个选择）
Option #1 : Adobe Acrobat is really nice. You can design form enabled PDFs and then use something like PDFSharp to manipulate the PDF document. You can create template PDF's that you dump your generated stuff into. I've done this before and it was pretty successful. I also used POCO objects nicely.
Option #2 : You could start creating XPS documents, which is XML based anyways. And they can be easily converted to PDF if necessary.
Option #3 : Run for your life.(might not be an option)
i-net Clear Reports 是一个不错的产品。它基于 Java，但您也可以使用 ASP.NET。有一座桥。如果您想使用 POCO，可以使用 .NET 版本。由于 Java 版本可以与 POJO 配合使用，因此即将推出的 .NET 版本也将与 POCO 配合使用。
i-net Clear Reports is a nice product. It's based on Java but you can also work with ASP.NET. There is a bridge. The .NET version is in work if you want work with POCO. Because the Java version can work with POJO that the coming .NET version will also work with POCO.