找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,极速登录

请上传宽度大于 1200px,高度大于 164px 的封面图片
    调整图片尺寸与位置
    滚轮可以放大缩小图片尺寸,按住图片拖动可调整位置,多余的会自动被裁剪掉
取消
tissot(uid:78035)
职业资格认证:无
不知道这算什么类型的需求,详见帖子内容吧。
用帆软官网下载的产品给客户做报表,期间用到各种功能、插件等等,报表完成了,测试运行不会有功能限制,但开发者并不太清楚用到了什么模块,以及是否收费。 客户购买时,也许只购买最基础的版本,运行时(不一定在哪个报表中,或点击哪个按钮时)会报错,提示没授权之类,这时才可能发现要买什么模块才能正常运行。 那么需求是:能否有个工具,事前就能自动检测开发的报表要用到什么模块,提醒开发者加入采购清单呢?
大屏真的有用吗?
首先,大屏的投入不小,但显示指标却相对固定,虽然能够胜任看几个有限的指标,但却并不方便决策者深入思考和发现问题,这类分析思考更适合借助PC或笔记本完成。 其次,对于日常来说,现在手机这么强大,几个固定的每日/每周业务指标,方寸之间一览无余,比大屏方便多了。 第三,对于定期、正式的会议场合,更需要的是灵活性更强的PPT,使用更多的是提前精心准备的会议材料,而不是大屏那点有限的内容。 最后,从可维护性方面看,为了保证大屏整体UI的稳定协调,一旦需要对局部进行改动,就必须考虑整体布局,因此新需求的实现也很麻烦。可见大屏的可维护性也很差。 那么,这样一个投入大、实用性低、可轻易被替代、可维护性差的工具,存在的必要性有多大?是否可以理解为是一种华而不实的形象工程呢? 对这样的大屏,作为个人,从短期考虑,急功近利一点也不能求全责备。但作为企业(不仅是用户,尤其是技术提供企业)的领导者,不需要考虑这种模式的未来吗? 真的应该如此功利的投入和支持吗?这样的大屏,真的能创造价值吗?或者说,有用吗?
单元格进图条缺陷
如图: 77034 在使用单元格进度条控件时,按照设计初衷,默认最大的那行数字(例如7.6万)填满整个单元格,其余行上的数字按比例填充。 但当报表存在限制性的查询条件时,例如:选择限定查询华东区域(而不是全国)时,查出的最大数字(例如3.2万)会小于全国最大的数字(本例中是7.6万),此时进度条没能填满整个单元格,而是只按照全国最高数字的比例(3.2/7.6)去填充单元格。 但实际上,因为此时的分析已经限定为华东区,在这个区域里最大的数字就是3.2万,3.2万这一行就应当填满整个单元格,而不是只填一小半(3.2/7.6),其余各行也应该按比例拉长。
听说FineReport要出9.0了?
很期待啊。 1、什么时候出? 2、有什么牛气的新特性? 能否先剧透一二?
实现金字塔图表
启用进度条插件后,预览显示不出内容
这个和Jar包有关系?我重装了最新版软件,jar包不也是最新的了吗? 看了下日志,有一个严重级别的警告,发现和背景(com.fr.general.Background.preDealBackground)有关。于是找了另一个普通报表,这次的报表连背景色都没设,果然此时即使启用插件,也可以正常显示。如果任意找个单元格设一下背景色(如图),预览立即又显示不了了。 (但即使不设背景色,仍然不能用插件将单元格设为进度条格式,否则还是不显示) 其他信息: 1、程序最初安装的是2016年12月的版本,安装进度条插件时提示版本不对,于是下载、覆盖安装了目前网站的最新版 2、报表用了很普通的demo中的销量表,简单的把销量字段做了个汇总,没有任何特殊设置 3、浏览器分别使用IE和Chrome,故障现象一致 4、日志截取: 2017-03-02 10:30:00 正常:开始转报表页为Html 2017-03-02 10:30:00 严重:com.fr.general.Background.preDealBackground(Ljava/awt/Graphics;Lcom/fr/stable/web/Repository;Ljava/awt/Point;II)V at com.fr.plugin.cell.progressBar.PresentImageBackgroundPreDeal.backgroundPretreatment(Unknown Source) at com.fr.web.core.HTMLWriter.clipReport2Html(Unknown Source) at com.fr.web.core.HTMLWriter.clipReport2Html(Unknown Source) at com.fr.web.core.HTMLWriter.writeReportToHtml(Unknown Source) at com.fr.web.output.html.HTMLOutlet.writeContentWhenNotFrozen(Unknown Source) at com.fr.web.output.html.HTMLOutlet.clippedPageOutput(Unknown Source) at com.fr.web.output.html.HTMLOutlet.clippedPageOutput(Unknown Source) at com.fr.page.ClippedECPage.output(Unknown Source) at com.fr.web.output.html.HTMLOutlet.writeReportPageContent(Unknown Source) at com.fr.web.output.html.HTMLOutlet.out(Unknown Source) at com.fr.web.core.A.qB.A(Unknown Source) at com.fr.web.core.A.qB.A(Unknown Source) at com.fr.web.core.A.qB.A(Unknown Source) at com.fr.web.core.A.qB.A(Unknown Source) at com.fr.web.core.A.EB.actionCMD(Unknown Source) at com.fr.web.core.WebActionsDispatcher.dealForActionCMD(Unknown Source) at com.fr.web.core.WebActionsDispatcher.dealForActionDefaultCmd(Unknown Source) at com.fr.web.core.A.nB.process(Unknown Source) at com.fr.web.core.ReportDispatcher.dealWithOp(Unknown Source) at com.fr.web.core.ReportDispatcher.dealWeblet(Unknown Source) at com.fr.web.core.ReportDispatcher.dealWithRequest(Unknown Source) at com.fr.web.BaseServlet.doGet(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:596) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:473) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:820) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:986) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:837) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:245) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
建议提供Tableau中的Story机制
Tableau中有一种汇报机制,或者叫报表发布机制,称为“Story”。 Story很适合两种业务场景: 1)固定周期的向公司高层汇报工作使用,例如:每周、月、季度的业绩汇报。 2)向多个部门、组织定期发布报告。 例如:对公司内各个部门发布每周、月、季度的经营报告; 例如:对公司外上游合作伙伴、供应商或下游分销商发布双方合作业绩的周、月、季度报告等; 例如:公司的业务人员,可以手持Pad,随时调出指定供应商(甚至该供应商的竞争对手)的上月、上季度业绩情况,与该供应商进行商务谈判,指出对方的短板和问题,竞争对手的进步等,随时随地方便的用事实和数字说话。 详解: 一个Story类似一个PPT文件,由多个“页”组成,可以象PPT一样顺序展示阅读。设计者在制作Story的每个页时,类似编辑PPT的每一页。例如: 1)可以将事先做好的N张报表和图形,嵌入Story的各页中,位置、大小等可自由调整。 2)可以在各页中添加文字、图片、变量等形式的说明与提示。 而Story比PPT强大的地方是:Story页中的报表和文字是“活”的。例如: 1)Story中的报表可以象普通报表一样,通过条件来查询。比如对一张月度销售报表,阅读者可以通过页面上事先设计好的查询条件“部门”,通过下拉框选择特定部门,查到各部门的销售情况。 2)与所查询部门销售业绩对应的分析评价(文字说明),可以事先编辑好(可存储在一个变量或一个数据库字段中)。在阅读者选择了对应部门后,显示在页面上。 一个Story制作好后,可以: 1)发布到Web页面,有权限的人可以登录阅读。 2)发布为pdf格式,但这种格式的报表是静态的,不能选择条件,但可以事先选择好,然后发布。例如: 一个企业有10个部门,公司的报表制作部门制作了一个对各部门月度销售业绩分析评价的Story。该部门每个月定期发布pdf报告,发布时可以选择不同部门,分别发布10个部门的销售Story(pdf版),供各个部门负责人决策使用。每个负责人看到的都是自己部门的销售数据,分析评价(文字)也是针对自己部门的问题,有针对性提出的。 3)分享。 好像可以分享到邮件中,也可以分享为一个Web链接,这个有点记不清了。 总的来说,Story提供了一种组合N张报表,并加以分析说明的综合汇报机制。 通过对权限、查询条件、变量的支持,使得一个Story可以供多个部门、组织互不干扰的使用。 这两点很有价值。
个人成就
内容被浏览30,028
加入社区4年239天
贡献:0

联系社区管理员|联系帆软|《帆软社区协议》|手机版|帆软社区|Copyright © 帆软软件有限公司 ( 苏ICP备18065767号-7 )

GMT+8, 2021-9-19 07:32 , Processed in 0.916732 second(s), 67 queries , Gzip On.

返回顶部