背景
早上,正愉快写着helloWord(Java)。老大对我来了句,搞个【 根据用户输入的markdow文本内容,将数据插入到PPT模板中,生成新的PPT文件。并且要可以在线预览以及编辑】
。(ps:就是直接照着人家的功能抄一个出来,参考网址:https://www.*******.vip)。并且跟我说Apache的Apache POI包是支持生成PPT的。
请看下图
1.用户先按照固定的markdow文本格式输入内容
2.根据用户输入的内容,转换成思维导图的形式展示。
其中,第一层的【中国传统文化艺术之美】是封面的内容,第二层是目录页的内容。第三层是章节页的内容,
第四层是内容页的内容。
3.选择对应的模板,生成PPT文件
开始干活
- 需求分析
1.封面页、结束页是固定的。直接占位符替换即可。
2.章节页、内容页里面的内容可以直接占位符替换,但是章节页、内容页数 需要提前计算好。比如3个章节就需要三个章节页。
2.目录页 的内容是动态的、目录页也是动态的。
自己目前想到的有以下三种方式:
1.在每个PPT模板预先设置好样式,然后取模板的配置(背景颜色、文本框位置等),所有的PPT内容全部由自己代码编写。注意,是从封面页、目录页、章节页页、内容页的样式都得自己写。
优点:灵活度高
缺点:全部自己手写,且涉及到调整样式,工作量大、所需的时间较长(后端就我自己)
2.在每个PPT模板上面、预先设置好占位符,然后把用户的数据直接通过占位符替换,把数据填充进去。
优点:不需要关心样式,直接填充数据即可,简单快捷。
缺点:灵活度低,部分内容是动态的。
3.将上面两张方式结合,大部分使用占位符替换数据,剩余的小部分通过代码动态插入。
- 技术选型
它可以用来操作 PPT 文件。Apache POI 支持两种格式的 PPT 文件:HSLF(用于旧版 .ppt 文件)和 XSLF(用于新版 .pptx 文件)。对于操作 PPT 文件,特别是 .pptx 格式的文件,Apache POI 提 供 了相应的 jar 包,其中包括:
poi
:Apache POI 的核心库 1poi-ooxml
:用于操作 OOXML 格式的文件,例如 .pptx 1poi-scratchpad
:用于操作旧版 PPT 文件的库
优点:
- 开源和免费:Apache POI 是一个开源项目,可以免费使用,对商业和非商业项目都非常友好 。
- 丰富的 API:提供了丰富的 API 支持,可以读写和操作多种 Office 文件格式,包括 PPT、Excel、Word 等 。
- 跨平台:由于是 Java 编写的,可以在任何支持 Java 的平台上运行。
- 社区支持:作为 Apache 基金会项目,拥有活跃的社区和持续的更新支持。
- 底层控制:用户可以对文档进行底层控制,比如对 PPT 的每个幻灯片、每个单元格进行操作 。
缺点:
- 学习曲线:由于 API 丰富,对于初学者来说可能有一定的学习曲线 。
- 性能问题:在处理大型文件或进行复杂操作时,性能可能不如一些专门的库 。
- 内存消耗:在读写大量数据时,可能会出现内存溢出的问题,特别是当数据量很大时 。
- 更新和维护:虽然 Apache POI 持续更新,但相比一些更现代的库,其更新速度可能较慢。
- 复杂性:对于一些简单的任务,使用 Apache POI 可能过于复杂,需要编写更多的代码。
2.Aspose的Aspose.Slides库
Aspose.Slides 是 Aspose 提供的一个强大的库,用于在 Java 和 .NET 应用程序中创建、编辑和转换 PowerPoint 演示文稿。优点:
- 多平台支持:Aspose.Slides 支持多种编程语言,包括 Java 和 .NET,可以在多个平台和技术栈上使用 。
- 功能丰富:提供了广泛的 API,可以进行幻灯片创建、修改、格式化以及集成多媒体元素等操作 。
- 高代码和低代码API:Aspose.Slides 提供了高代码和低代码 API,以及无代码应用程序,以适应不同开发需求 。
- 详细的文档和示例:Aspose 提供了详细的文档、示例代码和技术支持,帮助开发人员快速集成和使用 API 。
- 无需安装 Microsoft Office:与 Apache POI 不同,Aspose.Slides 不需要在系统上安装 Microsoft Office,可以独立运行 。
缺点:
- 商业软件:Aspose.Slides 是商业软件,可能需要购买许可证,这可能是一些用户的入门障碍 。
- 成本问题:对于小型项目或个人开发者,Aspose.Slides 的许可费用可能相对较高 。(嗯,不知道有没有魔法可以解除。。。)
- 学习曲线:尽管 Aspose.Slides 提供了丰富的功能,但对于一些开发者来说,学习和掌握这些功能可能需要一定的时间。
- 动手开干
一开始看到Aspose.Slides需要收费、果断选择了Apache POI(能省则省 ps:bai piao)
说干就干。当即开始研究起了Apache POI的使用,先把包集成到springboot项目后,开始熟悉API的使用,包括获取PPT文件,获取ppt文件某个幻灯片的文本、自己生成幻灯片、导出文件等等。以 下是集成的pom.xml
<dependency><groupId>org.apache.poi</groupId><artifactId>poi</artifactId><version>5.2.2</version></dependency><dependency><groupId>org.apache.poi</groupId><artifactId>poi-ooxml</artifactId><version>5.2.2</version></dependency>
1.获取ppt文件某个幻灯片的所有文本内容的时候(ps:占位符替换的前提是先获取到替换符),一开始复制了网上的demo代码运行,但是发现不太符合,因为网上案例的PPT文件样式简单,但是我的 PPT文件样式复杂多变。当我想着如何改代码的时候,灵光一闪,好家伙,这不是有GPT吗,我还废这个劲干嘛,GPT 启动!!!!!让GPT作为辅助,描述需求让它帮忙写代码,刷刷刷的几下,崭新的代码跃入眼帘、我直接就是一个copy,心里美滋滋。结果一看。
what?代码报错了?原来是GPT的代码里面。有部分办法是不存在的、还有部分的属性也是不存在的。立马纠正了GPT。又是刷刷刷一顿输出。我直接黏贴。心想:直接拿下。
当我复制黏贴后,
之前报错的地方不报错了,其他地方又报错了。接下来就是与GPT的来回拉扯。花了整整一下午的时候,最后可算是把幻灯片的文本内容都打印了出来。但是人麻了已经。
后面换了一张模板,发现又获取不到了。查了下资料, Apache POI 对样式复杂的PPT的支持不是很友好。折腾了一天。果断放弃,选择对Aspose.Slides进行尝试。
以下是集成Aspose.Slides的pom.xml
ps:我是把包下载后放到项目里面的,所以引入方式略微不同
<dependency><groupId>aspose.slides</groupId><artifactId>slides</artifactId><version>19.3</version><scope>system</scope><systemPath>${project.basedir}/lib/aspose.slides-19.3.jar</systemPath> </dependency>
aspose.slides对于复杂PPT文件的支持果然比较友好,哐哐哐一顿输出,利用递归的方式,把所有的文本内容都拿到了,可算是把占位符替换内容搞定了。
2.由于ppt文件的目录页里面的内容是动态的,意味着我不能用占位符的方式去处理。看下图。
一开始我的思路就不对了,我想着复制模板上面原有的样式,有多少个标题我就复制多少个,后面折腾了一下午,发现这种方式麻烦,换个其他样式又不行了。
后面换了下思路,目录页的内容自己写,成功解决问题。
3.markdow文本内容的封装问题。
一开始,老大的意思是说,我这边直接接受markdow文本的内容,然后我自己封装成对象插入到模板里面去,结果就是,我单单封装成对象就花费了一天时候,期间同样使用GPT写代码(踩了上面同样的坑)。
由于涉及到树形结构的层级补全,还有内容缺失的补全,还有对markdow文本内容格式的判断等等。发现由我这边直接处理markdow文本的内容太难处理了。后续老老实实让前端先展示成思维导图,
后再把数据给我。
后续的整体思路就是:
获取前端传过来的markdown文本对象(已经封装好的)、选中的模板Id--------》填充模板的封面页--------》动态生成目录页以及动态生成目录页的内容----------》动态生成章节页、目录页
--------------》填充结束页。
至此,功能的初级版本就完成了。后续我还做了一些优化,在模板上面增加了许多配置,后续需要的话,再把代码贴上。
还有ppt文件的在线预览以及编辑的实现,有空再单独讲。
总结
其实,我最主要是想对这个过程做一个复盘以及反思。
整个的功能实现,我发现了自己在这个过程中存在着很多问题。上面看似有点逻辑的实现过程,还是我在写这篇文章的时候,自己做了下整理的。
1.需求分析的时候,我没有先把需求整理清楚,ppt的生成、ppt的预览编辑其实是两个模块。
2.ppt生成的时候,模板中那些东西是固定的,那些是动态的。那些是需要两个结合的,都没有以前考虑清楚,都是写着写着才发现问题。
3.技术选型的时候,我并没有先把技术方案先列出来作比较,导致在第一个技术方案上面花了比较多的时间。
4.过于依赖GPT的代码。导致在调整GPT的代码上花了很多时候。有时候自己写反而会更快。(有时候是自己描述的需求不够清晰,导致的GPT的代码有BUG)
5.实现自己没有做过的复杂功能时,先去gitee或者github上面搜一下相关字眼,会有很多项目可以给到思路。
6.老大几句话交代的需求,其实是很模糊的,仔细分析下来,会发现里面所用的技术,所需要的时间,或者说注意的点,其实是很多的。包括熟悉各框架的API,整体的实现逻辑。
如何提升用户的体验感等等。