背景技术

Web应用开发已经高速发展了几十年，Web应用越来越普及，而对于从事Web应用开发的公司所面临的竞争也越来越激烈，因此如何高效、低成本的方式完成Web应用的开发是很多从事Web应用的企业都想解决的重要问题之一。

在Web应用开发的细分领域数据可视化这块，很多大公司都有快速构建数据可视化页面的工具产品，例如：阿里云的DataV，腾讯云的云图。这些工具无一例外的都是将一个Web页面拆分成一个个小的可以复用的组件，通过鼠标拖拽的操作和组件配置的操作快速的构建数据可视化页面。这样的工具提升了Web端数据可视化页面的生产效率，能让优秀的可视化资源得到反复的使用，更重要的是它降低了Web数据可视化页面的技术门槛，使得非专业从事Web前端开发的人员也能完成高质量的Web页面的研发。

但是这类使用拖拽的方式完成数据可视化页面研发的工具产品还是无法满足纷繁复杂的各类生产需求，例如：客户要求的展示元素超出了工具提供组件的范畴，可视化页面里存在有大量的跳转和下钻的业务诉求。因此一家拥有大量数据可视化业务并且具备良好web前端技术能力的公司都会自研类似的拖拽工具产品来满足自身业务的发展变化，同时可以运用这些工具积累自身数据可视化能力，最终在数据可视化方面形成自身独特的竞争能力和商业价值。

拖拽工具产品可以让页面的设计与研发工作变得更加简单，但是相对于传统Web前端的开发可视化页面的能力，拖拽产品制作页面的能力任然覆盖不足，例如本发明专利所要解决的场景正好是针对拖拽工具产品中页面下钻问题解决方案中的一个关键性技术。首先要总结和理解下Web前端的页面下钻的概念和处理方式，具体如下：

下钻是数据仓库里的一个重要概念，在《计算机科学技术名词》里下钻的定义如下：

数据仓库中的一种分析操作，沿着特定属性维度的层次下降，获取更详细的数据。

Web前端的数据可视化里的页面下钻本质上就是数据仓库下钻在浏览器端的一种实现方案。如果我们完全站在Web前端的角度而言，数据可视化的下钻页面的Web前端本质上就是：在一个页面里点击某个展示元素，页面发生了跳转或者是类似弹出对话框来展示新数据的操作模式。

这里我们再结合数据仓库里的下钻定义，点击元素和之后跳转出来的页面或者是类似对话框页面之间存在数据关联的问题即被点击的元素将自身所带的数据传递给下钻出来的页面或者对话框，新页面或者对话框会根据数据内容的不同展示不同内容的数据。

由上分析，页面下钻包含了两大功能一个是页面跳转，一个是数据传递问题。

在拖拽工具里解决页面下钻问题就是要基于拖拽开发页面的模式里完成页面的跳转和数据传递的操作。一般而言，在拖拽工具里解决页面跳转功能往往都是按照切换URL方式进行即页面整体跳转的方式完成页面的下钻，这样的模式跟web前端出现前的页面同步提交的模式一样，因为页面跳转是全页面的切换并且会进行大量的网络IO请求，这会导致页面加载速度变慢。

不过现在不管是固网还是移动网络，网络的速度都越来越快，加载速度也许不再是特别重要的痛点，稍微慢慢往往都是可以接受的，但是页面的URL式的跳转最大的问题还是数据传递的处理存在很大的问题。不同URL的页面数据的传递方法一般分为两类：

类1：服务端将数据写入到页面，然后把页面发送到客户端浏览器，浏览器在对数据进行处理；

类2：在浏览器客户端通过客户端技术进行数据传递，例如在URL后添加传递信息，使用浏览器的客户端存储机制。

对于拖拽工具而言，类1的服务端写入数据的方式一般和拖拽工具设计理念有冲突，几乎业界同类工具很少采用。类2是常用的数据传递方案，但是这个方案存在一些很难解决的问题，具体如下：

问题1：安全问题，页面直接的值通过客户端传递很容易被人利用，因为客户端的值传递基本都是可读的文本，所以人们是可以随意更改参数获取系统的敏感信息。就算使用传递数据的加密算法，因此加密和解密都是在浏览器端进行，安全任然无法做到根本保障；

问题2：传递数据的解析问题，我们从一个页面跳转到另外一个页面，跳转后的页面内容展示会因为传递值的不同而会有所不同，这对于拖拽工具而言就是跳转后的页面需要对于传递的数据做解析，解析后的数据会影响跳转后页面内各个组件数据的显示。而这个数据解析往往很难做到统一，如下：

场景1：A页面跳转到B页面，A页面传递的值是city=wuhan&type=1;

场景2：C页面跳转到D页面，C页面传递的值是name=xxx&firm=qq;

上面的场景里页面跳转都传递了两个值，但是两个值的业务含义明显不同，因为具体跳转场景里都会跟页面实际业务逻辑绑定，因此我们在拖拽工具里制作跳转后的页面，往往需要事先考虑到数据传递的业务含义，给每个展示组件以特定的数据解析，这对于一些非程序员的操作人员而言难度比较大，更重要的是一个页面拖拽时候跟一个页面级别的数据分析相关，这个流程设计往往会导致系统可用性大大降低；

问题3：跳转页面之间互动能力比较弱。这里我使用一个实例场景来说明：

A页面跳转到B页面，我们可以将A的数据传递给B页面，而B页面初始化加载时候使用这些传递的数据构建页面，那么在实际应用中跳转的B页面可能需要返回到A页面，这时候B页面反过来还需要传递值给A，但是A已经是加载好的页面，因此这种传值可能需要我们再一次初始化A页面或者因为重新初始化A页面不符合业务需求，那么我们就需要动态改变A页面里受影响的数据。而这种场景在目前时下绝大部分的拖拽工具里都没有相应的解决方法。

以上是跳转页面之间互动能力比较弱的一个场景，在实际生产应用中，如果A页面和B页面之间有跳转关系，从页面角度同时存在A页面往B页面跳转和B页面也可以往A页面跳转这是符合实际业务需求的场景，从组件角度，A组件交互变化会影响到B页面的对应组件数据变化，反过来，B页面组件里交互变化同样可能影响到A页面对应组件的展示变化。

而以上这些问题都是基于URL方式页面跳转很难解决的问题，而在页面开发被拖拽工具限制的场景里就更加的困难了。

以上讲到的是页面之间的跳转问题，在Web开发里弹出对话框的场景是和跳转页面一样常见的业务功能。在业内大部分的对话框往往都是某个组件自带的功能，很少有完整的对话框的解决方案。一般而言，具备拖拽工具里对话框都是使用iframe引用一个页面来实现的，其实这和页面跳转的原理区别不太大。因此拖拽工具里页面跳转的相关问题在对话框里同样存在，而对话框的场景往往是本当做页面的一部分来理解，因此跳转页面之间互动能力比较弱的问题在对话框场景就会显得特别的突出。

在数据可视化工具里页面下钻一般的处理方式都是按照页面跳转的模式进行了，所以在拖拽工具里的研发模式里，如果一个页面点击内部某个按钮或者组件，跳转到其他页面，那么我们就需要跟这个页面同级建立跳转后的页面，如果跳转页面很多，那么就会建立多个这样的页面，而页面与页面之间的业务关系实际中可能更加复杂，因此下钻场景在数据可视化工具里页面管理会非常麻烦。而在传统web前端研发中，我们对于有相互关联关系的页面往往会通过建立目录结构来实现。那么我们如何在拖拽工具也能有效管理下钻页面关系就是一个很重要的问题了。

页面下钻一个重要特性就是数据传递，但是下钻的数据传递往往不是和页面组件之间数据传递相似，因此页面之间的数据传递的解析往往会让组件之间数据传递产生分叉流程从而到时拖拽工具里数据处理问题变得更加复杂。

最后从用户体验和用户操作角度，假如我们使用者绝大部分都是非专业的前端技术人员，跳转后的页面想要符合业务需求那么首先就得考虑数据的解析处理，这样的过程会让很多非前端技术人员掌握拖拽工具跳转的业务流程的难度增加，从而很难普及这样的功能，导致工具可用性下降。

页面以URL形式的同步跳转，嵌入iframe弹出对话框的功能虽然无法有效解决页面下钻的全部问题，但是日常很多场景都还是非常实用的。如果我们只考虑上述下钻方式的缺憾，这里我们其实希望在拖拽工具里有一种可以基于单页面的下钻功能，即在一个页面下，URL不变的情况下我们如何完成页面跳转，弹出对话框，数据传递和组件交互等等问题。

本发明的浏览器拖拽开发中单页面级别的页面下钻工具与现有技术可以配合使用，已申请专利的现有技术包括：专利申请号为2020106481369，申请名称为《数据可视化开发用的拖拽开发组件及事件交互定义器》及专利申请号为2020106540598，申请名称为《大屏数据可视化开发中拖拽组件数据管理的方法和装置》。

本发明对比现有技术具有如下特点：

1.在拖拽工具我们使用一个画布完成页面下钻的研发工作；

2.对于页面跳转的场景，当我们开发跳转后的页面，本质是就是隐藏属于主页面的组件，这样就相当于清空了画布，那么我们就可以在画布上绘制子页面；

3.对于对话框的场景，我们在拖拽工具里研发页面时候，可以事先将需要拖拽的对话框显示在工具里，画布还是原理的画布，我们以这个对话框做为参考来通过拖拽来绘制页面；

4.在对话框的场景里，我们拖拽操作其实是按照主页面为坐标参考系进行页面的排版布局，这里就存在一个问题，我们绘制在对话框里的组件虽然看起来是在对话框的范畴，跟对话框有层级关系，但是其实并不是这样的，这样的后果就有可能在页面浏览时候对话框里的组件可能会先于对话框的背景框先展示出来，如果我们能让对话框和对话框的组件在浏览模式下真正做到主从的父子类级别的参考系，那么这样的展示问题就可以解决了。

单页面级别的页面下钻本质上只是通过元素隐藏/显示以及相应的交互在有限的展示空间里扩展了页面的内容，因此当具备下钻能力的页面初始化被加载时候，下钻后的页面以及对话框可以被当做页面的隐藏元素而已，如果我们初始化加载把所有的页面展示组件元素都一次性加载必然导致页面加载效率过低，如果我们的下钻可以按需加载即需要展示时候加载那么这样的执行效率就会大大增强，而时下很多拖拽工具的下钻都是一次性加载，导致这些工具下钻的场景性能开销非常大。