被老大毙掉的架构设计，真的很差吗？

原因：
在ipad上做一个类似于ibook的软件，其实相当于用webBrowser展现一套HTML页面（写了个JS框架控制内部数据的加载，所谓内部数据就是一套JSON文件和图片）

需求：
做一套生成他规定的内部数据的工具，要所见即所得，至少也要和他展现形式差不多的形式（HTML页面）进行编辑保存，PHP编写，支持导入导出

设计思路：
抛弃书先不谈（因为存储格式未定），理论上：页面和文本块，图片本身是树状结构，然后多个页面构成一个知识点，多个知识点构成一本书，从结构上看树状结构，如果要导入这样的数据进行编辑，那么我的思路是首先构造这样的树（在内存里）之后绘制他们

页面的绘制:
调用页面类的show方法。如果要绘制页面那么先构造一个页面的DOM树，之后往这个DOM树上挂载控件，给控件赋值（控件自己的show方法）

知识点的绘制：
一个知识点其实就是页集合，那么我会绘制第一个页面（show里调用第一个子对象的show），并在页面上添加一个导航条可以上下页滚动（调用指定页的show）

书本的绘制:
这里直接调用知识点的show会有点问题，因为知识点的滚动需要一个导航条，页的滚动又要一个导航条，我有个不成熟的想法，如果这样，我可以让对象自己的show没有实现方法，使用一个show对象进行绘制，这样我就可以使同一个对象在不同的上下文里有不同的绘制方式

整体上看，就是一个组合设计模式，一个解析器，一个DOM操作对象（用接口封装，使得可以透明的选择不同第三方的库）

结果：
老大觉得，你丫这么麻烦干嘛，写一个操作界面，每个操作用ajax解决，服务端不要架构，用各个小函数解决

问题：请大家客观分析真的有问题吗？

---

 

架构设计图：

 

 

确实还有一些我脑子里的想法没输出出来，其实image,page,text在我脑子里的设计其实是这样的，在我的内部存储数据里，我会要求数据长成这样：
{"divid":"control1","type":"text",value="hello"}
{"divid":"control2","type":"image",value="../image/1.png"}

另外，我会从一个HTML模版里生成DOM树对象，模版里有两个DIV，用CSS绝对定位，他们的id就是control1,control2，所以我会在DOM对象里find这两个元素，find之后，就创建textbox,img对象设置好值，挂上去，这些操作，都在他们自己的show里完成（也就是说，page对象创建DOM对象，然后呢，会在初始化image,text的时候传递进去，他们就能在所属的页面上进行绘制了）