我正在研究一个每天被攻击大约400,000次的Java Web应用程序。我应该添加一个功能，用户可以根据他们选择的标准下载医生和医院的PDF目录。有很多与目录相关的业务规则，一些医生/医院应该以一种方式显示，另一些则得到非常不同的处理，布局不是花哨，只是很多条件元素。许多条件元素可以被分解为固定模板，但是，有一组变体可以应用于多种情况和组合中，因此排列的数量使得详尽的模板列表变得不切实际。
我听说iText并开始玩它，它似乎非常适合我需要做的工作。我几天前发现（在我用iText取得重大进展之后），我所工作的公司将BIRT列为已批准的PDF生成解决方案。
我不认为BIRT对于这个应用程序是一个很好的解决方案，我想尝试使用iText代替。我对软件批准人员提出的论点是，iText是BIRT中的一个库，因此它应该被隐式批准（他们没有购买那个），BIRT太重了，我们甚至不会使用它的大部分功能和BIRT太紧密地耦合到数据源。我真的希望能够说一下BIRT在条件文档布局方面缺乏灵活性，但是我还没有找到BIRT在这方面的能力（这可能表明它的功能不是很好但是...很难根据遗漏的信息提出案例。）
我想知道的是，您是否同意iText是我的应用程序的更好解决方案？如果是这样，你会批准什么论点？如果没有，为什么BIRT更好？
非常感谢，我很高兴澄清我的问题中的任何令人困惑的部分。
答案 0 :(得分：0)
好吧，它看起来像BIRT支持脚本和＆amp;表达式，所以人们可能有这样的条件部分。
http://www.eclipse.org/birt/phoenix/ref/ROM_Scripting_SPEC.pdf
您可以在给定元素的OnCreate入口点中将给定元素的“display”样式设置为“none”。这可能会或可能不会重温文档的其余部分。
他们也分享他们的XML规范，所以在紧要关头你可以生成不同的XML文档来输入BIRT。
请记住，BIRT是开源的，所以如果你需要iText可以做到BIRT无法做到的事情，请添加它。