《模型》专题

我们常会做前台多语言模板，为了更好的实现多语言模板，CMF提供了良好的模板切换机制，我们在程序中定义了switch_theme钩子，通过这个钩子，我们可以制作各种模板切换功能，如多语言模板，手机模板； 在演示仓库的插件目录public/plugins我们提供了一个switch_theme_demo演示插件，通过这个插件你可以大体明白模板切换原理，你就可以实现自己的模板切换插件，如果你不想自己实现，

模板继承是 ThinkCMF推荐一种布局方式,它比上一篇讲的模板布局更灵活;模板继承就是你先定义一个基础的模板,在这个基础模板你可以设置很多个区块( block),然后在其它实际要渲染的子模板文件中用 extend标签继承这个基础模板,在子模板中定义name相同的 block,这样就可以对基础模板中定义的区块进行重载; 每个区块都是<block></block>这样的标签,如: <block na

TP 提供了三种模板布局使用方式,CMF 选用了模板标签方式,这样方便模板开发者手动,显式的控制是否要使用模板布局; 请不要在任何配置文件中开启模板引擎的layout_on设置 开启模板布局很简单,只要在要使用模板布局的模板文件开头增加如下代码: <layout name="public@layout" /> 表示当前模板需要使用当前主题下 public/layout.html 布局模板文件。当

模板 cmf 的模板分为前台模板和后台模板,它们都位于public/themes,只是后台模板目录名会以 admin开头,前后台都支持多模板; 前台默认模板simpleboot3目录结构: 模板目录下包含所有应用视图目录,比如 portal 应用视图目录就是 simpleboot3/portal; 后台默认模板也和前台目录结构类似,它位于public/themes/admin_simpleboot

模板注释支持单行注释，多行注释，模板被模板引擎解析不会在页面中输出这些注释，只有开发者可以看到，所以一些不想让用户看到的注释可以使用模板注释。 单行注释 {//单行注释方式一} {/*单行注释方式二*/} 多行注释 {/* 这里多行注释 这里多行注释 这里多行注释 */} 注:{和注释标记(//,/*)之间不能有空格。

普通标签 普通标签用于变量输出和模板注释，ThinkCMF普通模板标签以{ 和 } 作为开始和结束标识，并且在开始标记紧跟标签的定义，如果之间有空格或者换行则被视为非模板标签直接输出。 例如：{$name} 、{$vo.name} 、{$vo['name']|strtoupper} 都属于正确的标签，而{ $name} 、{ $vo.name}则不属于。 标签库标签 ThinkCMF的标签库默认定

模板常量 __ROOT__: 网站根目录，不带/; __WEB_ROOT__: 网站资源根目录,不带/,如果以前版本用__ROOT__来定位网站资源,方便以后cdn切换 __TMPL__: 当前模板根目录，不带/; 如:前台 default模板根目录是 public/themes/default 后台admin_simpleboot3模板根目录是public/themes/admin_simple

ThinkCMF调试模式的开关在项目根目录 .env文件里 # 关闭设置为false APP_DEBUG = true 开发时请开启APP_DEBUG，方便开发者调试； 开发完成可以改成false,关闭调试模式，进入生产环境！ # 关闭设置为false APP_DEBUG = false

该模块默认暴露出一个 BetterScroll 函数对象，这个对象直接从依赖库 better-scroll 获得。 链接 关于 better-scroll 详细的文档以及示例，请参考： 官方文档 官方示例

该模块默认暴露出一个 createAPI 函数，可以实现以 API 的形式调用自定义组件。并且既可以在 Vue 实例上下文中调用，也可以在普通 js 文件中调用。 注： 所有通过 createAPI 实现的通过 API 的形式调用的自定义组件（cube-ui 内置的组件）都需要通过 Vue.use 注册才可以。 createAPI(Vue, Component, [events, single])

主机模板保存创建虚拟机的配置信息，用于后续快速创建虚拟机。 主机模板保存创建虚拟机的配置信息，用于后续快速创建虚拟机。 入口:在云管平台左侧菜单项中单击 “主机/主机/主机模板” 菜单项，进入主机模板页面。 新建主机模板 该功能用于创建主机模板。创建主机模板配置参数与创建虚拟机配置参数大同小异。 新建主机模板前提条件 本地IDC：要求基础资源中存在启用状态的 云联壹云 平台宿主机，或云管平台已对接

异步模块 if (isIE8) { require.async('compatible-ie8.js', function(exports){ // ... }); } else if (isIE6) { require.async('compatible-ie6.js', function(exports){ // ... });

模块分块策略 coolie-cli 默认会将入口模块及其依赖模块都合并在一个文件里， 如果一些模块几乎被全站使用了，那么就可以考虑独立出来， 而不需将这些公共模块重复加载。例： "chunk": [ "./static/js/libs/**/*", // 分组0 "./static/js/3rd/**/*", // 分组1 [

模块标记 coolie-cli 的模块构建方式应该是比较特殊的一类，与 webpack 一样，都是另辟蹊径。 webpack：依赖模块放到数组里，数组索引值就是模块 ID。 coolie-cli：依赖模块全局标记 ID（三十六进制）。 coolie-cli 可以将长长的物理路径压缩成最短的字符，达到压缩率最大化，而不是将模块直接合并。 // module1.js define(function(r

handler模块简介 相信大家在看了前一章的模块概述以后，都对nginx的模块有了一个基本的认识。基本上作为第三方开发者最可能开发的就是三种类型的模块，即handler，filter和load-balancer。Handler模块就是接受来自客户端的请求并产生输出的模块。有些地方说upstream模块实际上也是一种handler模块，只不过它产生的内容来自于从后端服务器获取的，而非在本机产生的。