limu / magix Goto Github PK

1.支持location.path,location.search映射至page,自定义page映射规则.
2.支持以body为rootview
3.query对象增加search部分解析

关于queryModelChange

1. 当hash改变时，只需要告诉根view，再由根view向子view一层层的传递消息下去
2. 当某个view中queryModelChange return false后，则中断消息的传递

目前所遇到的问题

假设如下的界面

┏━━━━━━━━━━━━━━━┓
┃　　　　　　Ｈ　　　　　　　　┃
┃　　　　　　　　　　　　　　　┃
┣━━━┳━━━━━━━━━━━┫
┃　　　┃　　　　　　　　　　　┃
┃　　　┃　　Ｍ┏━━━━━┓　┃
┃　Ｓ　┃　　　┃　　　　　┃　┃
┃　　　┃　　　┃　　Ｚ　　┃　┃
┃　　　┃　　　┃　　　　　┃　┃
┃　　　┃　　　┗━━━━━┛　┃
┗━━━┻━━━━━━━━━━━┛

1. 我们有一个布局layout L
2. 我们有H S M Z四个view，其中Z套在M中
3. 当hash有改变时，告知L，L来决定是否向H S M发送hash改变的消息
4. 有时候我们不需要告知子view，所以我们会通过return false中断消息传递
5. 考虑hash改变时，L不需要告诉M H hash有变化，而S需要知道hash有变化，此时如果return false则S无法收到消息，而return true则又违背了M H不需要知道hash有变化的要求

根据遇到的这个问题，考虑return true或false外，提供一个return Array的功能，当返回值是数组是，我们只通知数组包含的view，这样或许能够解决掉这个通知的问题

左莫 (2011-09-07 10:37:06):
Controller里的config不应该和项目的ini文件关联在一起，可以在Magix下增加config方法配置，或者Magix.History启动的时候传入。

模板引入的作用

1. 界面与逻辑分离
2. 复用界面更方便
3. js代码开发与界面开发并行

maigx内置的mustache

1. 缺乏界面上的逻辑支持，对于稍复杂的界面，比如表格，需要根据数据动态的合并单元格，则无法在模板上直接完成
2. 正是由于1，为了解决1带来的问题，我们在view中引入了renderer对象，来增强逻辑处理，但这样做却让view中也混入了html代码(通常跟界面打交道的部分是需要很多html代码片断的),与我们引入模板的目标：界面与逻辑分离背道而驰
3. Mu在界面部分虽然无逻辑，但为了达到对一些数据有逻辑，在渲染界面前，需要做大量的数据处理工作才能达到要求。

未来的改进

1. magix本身并不需要模板，因此或考虑不内置模板， 在具体应用中由开发人员自行选择模板
2. 如果需要内置模板，考虑内置一个有逻辑的模板

目前工作

先搞清楚handlebars是否能满足我们以上的要求，如果可以，则使用它，如果不能，再说~

主要集中在view这一块的API名称

方法：
view.queryModelChange=>view.hashChange(qm) //参数仍然使用queryModel

事件：
view.rendered=>view.rendered
view.beforeRebuild=>view.unload

当然事件还有别的，对于应用中只需要知道这2个即可

是否应该对所有事件代理

1. 通过mxclick可以在模板上快速注册事件
2. 通过events下的click与模板上注册的事件挂钩
3. 这样的方式比较直观，也较动态绑定事件方便的多

但是这样的事件要求事件能冒泡，因为magix中，会把当前view中要用到的事件比如click,mousedown等在view的根节点中注册事件，如果事件不能冒泡，则无法在根节点捕捉得到，也就无法处理

常见的不冒泡的事件如focus,blur,change,submit等，而这些事件也不是在所有浏览器中都不冒泡，是有浏览器差异的(这块最好能把各浏览器版本的支持情况列举下)

通过阅读jQuery的事件部分和KISSY的事件部分，它们对于处理不冒泡的事件思路是一致的，以submit事件举例，在不支持冒泡的情况下，如果当前节点需要监听submit事件，则首先判断当前节点下是否有form表单(只有form表单才有submit)，如果有，则给这个节点绑定click,keypress事件(既然submit无法冒泡，那么我们就监听能触发submit并且冒泡的事件)，当click或keypress发生时，我们这时才去给form绑定submit事件，在submit监听中，再手工去进行冒泡(找parentNode，触发submit)，直到最顶层。

另外对于change事件较复杂，blur,foucs需要兼容一下浏览器，不过原理上跟上面所提到的submit都是一样的。

对于需要处理的事件大致为以下事件：

1. blur
2. focus
3. focusin
4. focusout
5. mouseenter
6. mouseleave
7. mousewheel
8. valuechange(change?)
   参考KISSY事件部分得到的以上8个事件

如果做事件的代理，我们要注意的事情

1. 应用中是否需要对这些不冒泡的事件都进行代理？(change较麻烦)
2. 如果做代理需考虑这个场景：
   • view点击某个按钮弹出一个弹出层A，弹出层A中点某个按钮弹出弹出层B
   • 当鼠标点击在A外部时，A B都需要隐藏
   • 当鼠标点击在A内部B外部时，A不能隐藏，B需要隐藏
   • 当鼠标点击在B内部时，A B都不能隐藏
     *点击在A内部B外部时，仍需考虑A B都不隐藏的情况
3. 对于2的应用场景，需要在冒泡这一块仔细考虑，那么我们是不是要对所有的事件进行手动冒泡才可以？

目前magix中用到的标识

1. pathViewMap部分，这样做的映射：'/plan/list': 'app/views/layouts/default'
2. 地址栏中显示是这样的：#!/plan/list 或 #!/plan/list/
3. vframe中引入view是这样的： app/views/header

需要做的工作

1. 有时同样引用一个view，有时候需要映射，而有时候不需要映射（考虑要么统一映射，要么去掉映射）
2. 有时末尾会有/，而大部分时候是没有的(考虑统一添加或去除)

helper中的getTemplate，增加是否同域的判断来读取view的模板文件。

从页面<script type="text/template">内容中获取模板

确定magixjs完整的打包方案

model和collection的好处

1. 与后台数据库一一对应
2. 更直观的操作数据(删除或更新操作，操作对应的delete或update方法即可)

magix中model和collection

1. magix中更新view界面是刷新整个区块
2. 如果数据有改动，仍需手工去刷新整个区块，并非magix自动完成
3. 在更新界面时，如果数据是原始数据而不是数据对象(model)，那么在界面上书写模板这一块将会方便许多(如一些地方数据需要参与运算)，而如果用model还需要先toJSON后才能操作
4. 事实上如果用model或collction，那么后台在给出原始数据后，到magix中，自动转成model和collection，而在更新界面时，更多的时候需要转成原始数据
5. 事实上在magix中对数据这一块更多是在更新界面时使用

model和collection的去留

鉴于maigx的更新界面方案，目前考虑去掉collection，保留model，不把list转成数据对象(model), 那么对于需要较直观的更新数据，可考虑在model上增加静态方法如get put delete post，引入modeltype标识怎样更新一条数据。

考虑一份远端数据在数个VIEW中需要使用

1. 这份数据由谁加载进来？
2. 加载异常如何处理？
3. 如何方便的共用这一份数据？
4. 数据需要更新时如何操作？

目前可供使用的有

1. 应用中全局数据设置和获取

参考gmail，hash改变后，view的刷新使用display=none隐藏上一个，然后重新创建当前需要展示的view，当需要后退时，可者hash再次改变时，隐藏当前的view，把之前隐藏的view再次显示

1.可以完整的保持上一个view的状态，比如checkbox的选中等，不需要hash维护
2.避免重复创建dom节点的开销

magix目前是整个刷新掉view的做法，使用这种做法还很困难，不过这是一个很好的借鉴方案，某些时候隐藏view能带来更好的效果，比如对于需要还原界面的地方

考虑如下代码：

KISSY.add('app.views/home',function(S,MxView){
     return MxView.extend({
           render:function(){
                  var self=this;
                  S.use('med-calendar',function(S,Cal){
                        if(!self.exist)return;
                  }):
           }
     });
},{
    requires:['magix/view']
});

注意render方法中 **if(!self.exist)return;**代码，由于S.use是异步载入的，那么很可能在载入后，该view已经被卸载掉，导致接下来在访问或使用DOM节点时，出现异常

类似的还有model异步获取数据、直接使用XHR与后台交互等，如果未加eixst判断，很可能在用户已经点击到别的地方，当前view已经卸掉后这些异步请求才返回，而此时访问界面通常都会由于节点已经不存在而导致异常，影响OPOA的后续运行，所以需要添加exist判断当前view确实存在才进行操作界面

通常我们在开发中很难记得去添加exist判断，导致后期排队错误非常困难，因为缺少判断并不会立即导致程序出错，这种出错往往在网络不太好，而用户切换view出现的

我们对于konckout来看这个问题

对于konckout伪代码如下：

Model={
   name:ko.observe('a');
}
<span data-bind="text:name"></span>

我们在更新界面时如下操作：

Model.name('b');

注意：

1. 更新界面时我们操作的是Modle
2. 更新Model时我们使用Model.name('b')而非Model.name='b'

konckout把更新界面的动作在内部处理了，它内部有判断当前节点是否存在才进行更新，而magix是采用大面积更新的方式，很难做到对所有的节点操作进行代理，因此这块是一个比较大的隐患，后续需要解决这个隐患才能使magix更安全健壮