GithubHelp home page GithubHelp logo

magix's Issues

view可否display=none代替销毁

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

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

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

magix代理事件

是否应该对所有事件代理

  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的应用场景,需要在冒泡这一块仔细考虑,那么我们是不是要对所有的事件进行手动冒泡才可以?

queryModelChange

关于queryModelChange

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

目前所遇到的问题

假设如下的界面

┏━━━━━━━━━━━━━━━┓
┃      H        ┃
┃               ┃
┣━━━┳━━━━━━━━━━━┫
┃   ┃           ┃
┃   ┃  M┏━━━━━┓ ┃
┃ S ┃   ┃     ┃ ┃
┃   ┃   ┃  Z  ┃ ┃
┃   ┃   ┃     ┃ ┃
┃   ┃   ┗━━━━━┛ ┃
┗━━━┻━━━━━━━━━━━┛

  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,这样或许能够解决掉这个通知的问题

app中,共享数据的问题

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

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

目前可供使用的有

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

magix能否与app解耦?

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

API名称修改

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

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

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

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

多种getTemplte方式

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

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

view.exist问题

考虑如下代码:

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更安全健壮

magix的model和collection

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标识怎样更新一条数据。

路径标识的统一

目前magix中用到的标识

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

需要做的工作

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

模板部分

模板引入的作用

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

maigx内置的mustache

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

未来的改进

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

目前工作

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.