实习日记->最近两周的总结

      最近好久都没有写过文章了,主要是这两个星期都在搞一个问题。在别的大牛看来,可能根本就是小问题,但是确实是花了我两个星期才搞好。接下来就好好的说下。

 

     首先说下需求情况。数据中的表结构如下:

 

Father

Son

det

Forest

det

Ddc

det

util

Cmm-uri

util

sketch

Cmm-uri

Ddc

Cmm-f

ddc

itemmisc

itemmisc

Core

ddc

Smonitor

Smonitor

det

 

我们可以看到各种父子关系。如:det->Ddc->Smonitor等,特别注意到这里还有一个环 det->Ddc->Smonitor->det.这个在真实的数据中是存在的。然后我要得到的结果就是用有向图来展示这个结构。当然真正的数据要比这个复杂的多,而且数据量也是很多的。

 

       其实这个需求我已经写过一次文章了。本来我以为我当时已经完成了的,产生这种想法的原因是我使用的是我自己创建的测试数据。而不是采用真实的数据,这就导致我的复杂性一下子就小了许多。而且貌似性能也不错。当真实数据上来以后,我发现根本就没法访问,而且浏览器会卡死。我看了一下源文件的大小,纯文本的html文件居然有4M的大小。我师兄看了一下我用的算法,深度优先的递归遍历,就说可能中间有环了。查看数据库,果真如此。而且展现的方式也需要改变一下,要使用图结构而不是使用TreeTable的结构。

 

       这个需求就让我犯难了,我看过很多的图表框架。画饼图、柱状图和曲线图的很多,但是画有向图的还是没见过。想着是自己的见识太少了,就问了问师兄,还真有。他给了我个网址 dracula .这个框剪可以画出有向图结构。当时很兴奋啊,上来就看了示例,感觉蛮简单的。就试着写了个简单的示例。虽然是可以展示,但是有几个问题。最大的问题就是不能指定位置,这个框架中的图节点的位置是通过它自己的算法计算出来的。这让我感到很是沮丧,没办法指定位置,就没什么用了。但当时还是不死心,就尝试着看看框架的源码,看能不能修改一下。我就发了三天来看源码,说来惭愧,我硬是没看明白算法。既然没得改,就只好找其他的路了。接着就在这个网站上看看了,发现了一个可以可以指定位置的框架。使用起来比原来的还简单些。

 

       这个是第二个框架的地址 js-graph ,是基于js 和 css的。示例的效果也不错。然后当时找到这个框架的时候我用的还是测试数据,发现展示起来很方便,所以很轻松的将第二版给搞定了。但是一用到真实数据,就发现页面根本没有那么大的空间来放这些图节点,同时节点节点之间的连接线很多都没法显示,看来又是失败的作品啊。

 

       既然不能一次性全部展示,那么Ajax可以派上用场了。直接用Ajax+json来处理,发现没办法正常的显示数据。这时,我回过去看看了框架的说明:In order to minimize the work for the user that writes html pages with graphs, I choosed to use
 a "declarative strategy", i.e.: rather than ask the user to write javascript code to create the graph, I thought it would be great if he can simply declare that a html element is a node or a connector,  or any other kind object involved in the graph So, I decided to rely on css classes for this task in order to keep the document a valid html page and also ease up the definition of objects layout. 看作者都说了,不需要些JS。也就是说没办法使用JS动态的添加了。

 

      不过,既然选了就要深入的研究一下。看了源码以后发现,我动态添加到DOM树中的东西,被框架给删除了。也就是,我本来是可以通过JS来添加或者删除节点的,但是由于框架内部修改了DOM树,所以直接的添加时不行的。所以又尝试着修改源码,这时候测试用的数据就是真实的了,不能老是因为数据的问题而出问题啊。

 

       使用这个框架时每个节点由两个部分组成节点<h>标签(当然也可以用其他的),边节点<div>.同时还包含一个箭头的图片。当页面载入的时候,框架会获得这些个节点。节点和边都有相应的对象Block和Connector,将这些Html标签用对象来保存。同时还有一些其他的类,大概的结果如下 :

 

对于Block对应的HtmlElement他不做其他处理,只是将数据保存。但是对于Connector,就做了很大的手脚。从图上可以看出,Connector还关联了两个类。Segment代表的是连接的线的一段,他将一条连接线分成了三段。ConnectEnd代表的连接线末端的箭头。他的手脚就动在了这里。对于一个Connector,他都会创建三个Segment对象和一到两个ConnectEnd对象。每个Segment都对应了一个新的<div>节点。然后将原来的那个节点删掉,这样我本来只添加了两个节点,被他这么一搞变成了四个了。我要是再去处理我原来添加进去的节点,根本就不存在了。既然他能够添加,当然我也可以删除撒,我给Segment和Connector都增加了一个删除的方法。将它创建的对象全部删掉,然后页面载入的时候重建。这样是可以了,但是毕竟框架还有很多其他的东西,我这么删除肯定会有潜在的bug的。这不我测试的时候显示三层依赖关系是没有问题的,但是到了第四层就不行了。删除的时候页面上就会显示残留的一些边痕迹,同时其他的连接线就会显示不正常了。看来还是悲剧了。

 

       使用Ajax的路是走不通了,还是得走页面刷新的路了。使用页面刷新,就比较的简单了。一次性将所有的信息输出到页面上就可以了,不过这里还是要注意环的处理。用递归,肯定就要用到栈啊。用栈来保存递归路径上出现的信息,如果第二次出现就不处理了。到这个时候基本上就完成了。看看我走的路,很崎岖啊。尝试过很多的框架,很多的方法。其中很多时候我都想直接用Table输出得了,但是转念一想,这是自己在公司做的第一个东西,不能就这样算了。所以还是一直的坚持了下来。最后能够做完,达到师兄的要求,这点付出还是值得的。

 

       当然,这还没有完。虽然基本的功能是实现了。但是性能上还需要改进,特别是在数据库端,我是采用的存储过程+临时表的策略实现的。当请求多的时候,频繁的创建和删除临时表对性能的损耗是比较大的。所以还要继续的改进。

 

 

       通过这次的过程,是我在选择使用框架的时候有了新的见识。我不仅要知道框架适合干什么,还要知道他不适合干什么。特别是适不适合自己的业务需求。如果不能够适合自己的业务需求,功能再强大也是白搭。我想这也是公司很多的框架都是在原有的框架上进行改进或者干脆是重新写一个的原因吧。

 

 


 

展开阅读全文

没有更多推荐了,返回首页