关于 "动态" 模板的憧憬

大概是一年多以前还在一淘实习的时候, 萌生了这么个想法, 如果一个模板可以是基数据驱动的, 那能胜任的工作就从现在更多的格式化字符串和其他一些简单的东西变得更加复杂和强大. 当然因为是数据驱动的, 在写这样一个模板时, 也将体会到数据驱动带来的逻辑上的优势. 不过也是因为各种原因, 当时做完第一步的模板解析之后, 就没再继续了. 因为要做好, 略微困难, 而且不像原来做Prever什么的时候, 虽然代码总量大, 但可以分开成很多小块, 今天断开一点, 明天稍微回想下继续写就好.

除此之外, 另外一个数据驱动的小库, Drop(未更新), 倒是做了出来, 虽然还有诸多不完善, 到最后肯定也免不了被重写的命运… 但就实践来看, 这种方式的确是很实用的.

那回归可能会基于Drop(顺便Drop最近的版本是基于VEJIS的)之上的这个模板系统, 之前取名叫Sonne, 以后多半也是这个名字吧. 前些时候了解了下lisp语言, 才发现它和lisp之间还有一点点相似之处. 这里贴一段很久很久以前写的示例.

<!-- comments -->
{header
    <img src="xxx.jpg" />
    <h1>{title}</h1>
    <p><span>{tip}</span><span>{tip}</span>{description}</p>
}
{nav
    <ul>
    {items[]
        <li>
        {#link {
            {@hash page}
            {@value home}
            {@inner {home}}
            {@class nav-link}
        }}
        </li>
    }
    </ul>
    {#if {
        {@if {#cookies loggedin}}
        {@then <a href="#logout">log out</a>}
        {@else <a href="#login">log in</a>}
    }}
}
{content
    <div>
    {#async {
        {@type html}
        {@url content.ashx?page={#hash { {@name page} {@default home} }}}
        {@loading
            loading...
        }
        {@loaded {data}}
    }}
    </div>
}
{sidebar
    <div>
    {#async {
        {@type json}
        {@url sidebar.ashx?page={#hash { {@name page} {@default home} }}}
        {@loaded
            {data
            <ul>
                {list[]
                <li>{text}</li>
                }
            </ul>
            }
        }
    }}
    </div>
}

还是大概能看出来吧? 大括号开始, 紧接一个字母的, 是闭包, 在里面可以直接书写文本内容. #号开头的则是组件(当然, 你可以定义自己的组件), 里面的@开头的是属性, 也可以理解成参数. 包括if都是以组件的形式存在的, 所以这种一般性让Sonne具有更强的扩展性. 好吧其实, 还有个原因是我实现起来会相对容易, 不用处理更多的特殊化的语法… 😛

再以#async组件为例, 可以看到url属性对应的字符串中存在另一个组件, 所以实际上, 组件是有 “返回值” 的, 可以是字符串, 也可以是文档片段. 因为是数据驱动, 当数据发生变动的时候, #async组件所管理的文档片段也就随之变化了, 并且因为是组件, 也可以很容易地实现定时更新数据.

当时一直期望这东西能改变Web开发的某个分支, 其实现在也有这个想法, 但也不知道最后能不能做出来… 记得后来看到过某个库, 也有类似的功能, 但印象里并没有Sonne强大,,, 具体哪里没有… 忘记了…

浅谈Web程序设计中的面向数据的编程(DOP)

所以说, 趋势就是趋势, 并不在于谁提出来, 该有的东西自然便会有. 我不知道我们这一代人是否算是见证了DOP的诞生, 但至少在这些年, DOP被用得越来越多了.

说到这个, 首先想提两点. 一个是之前众所周知的变成模式, 面向对象编程(OOP). 对与我来说, 面向对象在我的代码中扮演了相当重要的角色. 它让程序内部的交流变得更加清晰, 提升了程序的可读性, 降低了出现bug的概率. 在有些应用上, 到目前还是不能替代的. 另一个是今后Web编程的发展, 我目测会有几个大方向: 1. 基于Canvas或CSS3的Web游戏. 2. 功能复杂的Web应用程序(如在线办公). 3. 以内容呈现与交互为主的Web页面(如SNS). 只所以想要提这两点, 是为之后将要说到的OOP的局限性, 和DOP的应用范畴做铺垫.

那首先说说, 什么是DOP. 老实说, 我并非是从这个名字开始接触这个概念的, 而是从很多Web页面的改变上开始思考这个问题. 不过很自然地, 使用了同一个词语来描述这样同一个概念. 其实其中有一点YY的成分, 但我想也应该八九不离十.

如果说OOP让人们只用关心如何去调用一个功能, 而不用关心功能的实现的话, 那么DOP则只用人们去关心一个模块/对象所管理的数据, 而不用关心这些数据的改变会对其他模块/对象造成什么影响. 当然, 对自己的影响还是要关心的. 其实细想, 在一些高级编程语言中, 对象的属性就是一种简单地DOP模型. 但显然, 它是局限在某一个对象上的. 然而很多时候, 同一个数据在多个对象上是公用的, 这或许就是DOP和传统OOP一个很大的区别, 也是传统OOP的局限.

但说到这里, 大家可能也会有种想法, 认为DOP也是OOP. 我认为这种想法是正确的, DOP的最佳实践应该对象化/模块化, 只是与直接调用其他对象的方法不同, 通过数据来间接达到目的. 这一点来讲, 倒和面向事件的编程(EOP)有些相似, 但事件是瞬时的, 而数据则是可持续的. 或许DOP约等于OOP+EOP+Data?

近年来, 在很多网站中出现了Hash, 很多MVC框架也支持相应的技术, 极大地方便了复杂的无刷新页面的实现, 这应该算是典型的DOP. 不过如果仅仅是这样, 还只能说是Hash上的数据在和整个页面一个对象交互, 这就有点伤感了. 还好看到一些框架, 并非这样的如果, 比如淘宝的MagixJS似乎就不错. 不过很显然, DOP也有其局限性, 毕竟中间穿插了一个环节, 在效率上或许比不过传统的变成手段. 所以像Web游戏的有些部分则是不便于使用的, 但我想做做UI还是完全能够胜任.

按我的理解, 相对于OOP, DOP能进一步减小复杂程序的思维难度, 提高开发效率, 以及降低bug的概率, 应该是未来Web编程某些方面的趋势, 于是我也有自己的DOP框架计划, 只是准备在DOP的基础上, 增加强大的模板功能, 也许未来, 很多AJAX操作, 都只需要一个简单的模板了.