自从向日葵甘特图发布以来，受到了很多朋友的关注，也提到了很多的功能需求点，其中很多集中在数据的提供和处理上，我们以前的数据都是完全参考Project的数据格式进行开发的，不过随着开发的深入，我们渐渐理解到，Project的XML格式毕竟是一个本地应用程序的数据格式，直接移植到网络上会遇到很多问题，我们有时候会接收到用户的如下抱怨：
1.我的数据很多很大，生成一个庞大的XML文件严重影响服务器性能，而且在客户端加载这么大的XML文件浏览器也很慢；
2.我的数据很分布在多个地方，如何整合在一起？
3.我的数据之中没有大纲，给每个任务生成对应的ID和大纲数字(OutlineNumber)比较复杂；
4.数据能分块下载么？
现在，我们终于找到了这个问题的解决方法，优化了甘特图的数据处理逻辑，并已经开始内部测试，现在简单的介绍一下新的处理处理逻辑。
在新的数据逻辑下，不再使用Project格式的数据的从上到下的线性读取逻辑，而是采用XML的顺序处理逻辑，这个逻辑简单介绍如下：
1.每个大纲任务，都按照从上到下的线性逻辑读取其子任务，不必一次读完；
2.如果没有必要读取某个大纲任务的子任务（例如被折叠了），则可以跳过不读取，而不是像原来的ProjectXML格式那样必须先读取完成才能
参照以上逻辑，从原理上即可以实现以下功能：
1.按照大纲下载任务，即只有某个任务被点击展开的时候，才去服务器下载其子任务，这样就可以将甘特数据按照大纲灵活的划分为无数的小块，节省服务器和带宽；
2.分页下载任务，假如每个概要任务下的子任务本身就很多，数据很大的时候，可以每页只下载指定个数，用户需要查看某一位置的时候，再去下载该位置的数据；
3.其他的更灵活的分块下载逻辑；
当然，我们新的数据格式会对现有的模式产生一些影响，最大的影响是原有的ID属性，也就是显示在甘特图左侧的列，这一个列的数据在以前的数据加载逻辑之中充当极其重要的功能，而在新的数据处理逻辑之中，降低了其地位，主要是基于以下考虑：
1.用户的任务数据很多，或来源很多的时候，很难为每一个任务按照顺序分配一个ID,尤其是分块数据下载的情况下，如果要为每一个不发送到客户端的任务也保留一个ID是不值得的；
2.在用户修改XML数据的时候（特别是添加、删除、移动等涉及到任务大纲的变化），甘特图对ID值的维护比较复杂，最关键的是，通常都需要下载所有的任务以更新它们的ID，实际上是得不偿失；
3.在新的数据结构下，不需要使用ID值来处理相关逻辑；
ID值在新的数据架构下将和原来的UID值属性的处理方式一致，也就是说甘特图对这个属性只读不写，原有的getTaskById()方法为了保持兼容将保留，不过不再建议使用，因为这个方法会很耗性能，尤其是数据从服务端下载的时候；对ID值的更改最明显的效果就是在任务顺序或大纲发生变化之后左侧显示的ID列将不会随之变化，因此，左侧的ID列会显得比较奇怪，因此，我们建议在左侧显示其他列（例如UID），或者干脆不显示左侧列，如果你确实想保留原来的ID处理方式，可能我们新提供的功能就将无法应用了，而且会造成性能问题；
我们实现了一个简单的分块加载数据的功能范例，可以点此链接查看：
