该问题反馈截至日期为周4晚上12点前。

该问题反馈完毕后不再进行投票，请大家直接表明观点。

此问题不象规范条目那么简单，中间需要考虑的点很多，请大家多参考spec文档，相关的前端平台与装载器，综合考虑现有产品线开发情况，提出观点。观点请尽量详细，有理有据。

本讨论截至日期12-14,星期5中午12:00。

本讨论结束后，不再发起投票，请大家直接表明观点。

现有标准可见http://fe.baidu.com/doc/ecom/

主要讨论的是api部分。我扔几个问题先：

关于控件id自动生成

是否需要？现在创建控件都需要手工id

关于子控件管理

现有两种实现的分歧是：

1. controlMap（kv）作为子控件容器，直接点添加
2. children（Array）作为子控件容器，addChild添加

之前简单沟通的结果是使用children更好些

现在存在的问题是：

1. addChild的形式
2. 批量添加如何做？是否需要内建的方法支持通过模板和容器元素注入
3. 如果需要，内建方法对模板中的控件id如何管理
4. 内建方法返回kv还是array？是否自动addChild？
5. ui.init方法返回的是kv，是否需要保持一致，返回Array？

关于事件

1. 是否需要能够通过on添加listener？现在是未支持
2. event argument是否需要统一object？现在是未统一

还有

大家可以补充。

基础框架为了最终的使用，在代码里写的是require('css!xx.css')，这时在webserver中会请求.css，但是调度的时候往往.less没有编译成.css，很麻烦。

建议webserver对.css的文件做特殊处理，如果文件系统里没这个文件，就去读对应的.less再编译后送过去。

进一步，建议哪怕有.css文件，也找一下同名的.less，如果.less比较新，还是用.less的，这个要看到底有没有人会真的同时写.less和.css了，有的话就不能这么做

edp svn add .

自动添加文件到svn，这个大家都懂的。

Yeoman体系中集成了 LiveReload 功能，支持内容修改后浏览器自动刷新。是否考虑在 edp webserver 中也集成一下。

参考Yeoman Wiki：

yeoman server:reload forces the port to be LiveReload standard port: 35729 and prevents the automatic default browser opening. Handy for those wishing to use livereload extensions with other systems / HTTP servers than the one provided by Yeoman out of the box.

目前需要迁移的功能

Fer --gen_app
Fer --gen_widget
Fer --gen_material

不同的项目存在不同的需要，因此code-gen需要提供几种常见的模板

1. Javascript规范

1.1 一var一变量

a.必须（MUST）

var v1 = 1;
var v2 = 2;
......

b.不强制，允许下面情况

var v1 = 1, 
    v2 = 2,
    ......;

1.2 变量声明位置

a. 必须（MUST）即用即声明

b. 必须（MUST）在function起始的地方

c. 都可以，不做强制

1.3 字符串

a. 必须（MUST）单引号

b. 必须（MUST）双引号

c. 不强制

1.4 对象直接量的key { key: xxxx }

a. 非关键字不允许（MUST NOT）wrap，关键字使用和1.3一样的规则wrap

b. 必须（MUST）使用和1.3一样的规则wrap

1.5 行分隔（if，字符串相加等）

a. operator前分隔

if ((condition1 && condition2)
    || (condition3 && condition4)
    ||!(condition5 && condition6)
) {
    doSomethingAboutIt(); 
}

b. operator后分隔

if ((condition1 && condition2) ||
    (condition3 && condition4) ||
    !(condition5 && condition6)
) {
    doSomethingAboutIt();
}

2. HTML&CSS规范

2.1 html id

a. 字母小写，中划线分隔“-”

b. 字母小写，下划线分隔“_”

c. camel

d. pascal

2.2 标签闭合

a. 标签必须（MUST）闭合

b. 标签允许闭合，也允许不闭合

c. 标签不允许（MUST NOT）闭合

2.3 boolean类型属性:如checked

a. checked

b. checked="checked"

2.4 使用HTML5新增标签进行布局（header、footer、sidebar等）

a. 强制(MUST)

b. 允许(SHOULD)但不强制

c. 不允许(MUST NOT)

2.5 css id选择器

a. 允许使用，不做限制

b. 不允许使用（MUST NOT）

2.6 部件class命名（例：文章标题）

a. 允许（SHALL）article-title

b. 必须（MUST）title，不允许（MUST NOT）article-title

c. 必须（MUST）article-title，不允许（MUST NOT）title

2.7 是否允许使用ie filter

a. 允许

b. 不行（MUST NOT）

3. 文件夹结构规范

3.1. 常见目录命名

a. scripts | styles | images | icons

b. script | style | image | icon

c. js | css | img | ico

3.2 js对象路径和目录的对应

a. 完全对应。jn.ShowCase -> jn/ShowCase.js

b. 目录全小写，下划线分隔。 jn.ShowCase -> jn/show_case.js

c. 目录全小写，中划线分隔。 jn.ShowCase -> jn/show-case.js

3.3 引入第三方包的路径

a. 直接放在${path}中的一级目录下，如${path}/lib(package)

b. 放在${path}/src中的一级目录下，如${path}/src/third_party

4. package规范

4.1 package和业务项目的统一

a. 需要统一

b. 不需要统一

需要将原来er-server和tools/server.js的功能移植过来。

之前的讨论中不涉及详细的注释相关的话题。在整理最终版本的时候，发现对于注释，还是需要很好的规范，故发起此讨论。

现在是北北按着gcc（不是gnu c compiler）整理的，请大家提意见。

最终版本的草案在这里。
http://fe.baidu.com/doc/ecom/std/javascript-code-style.text

可能出现的场景

loader config在哪里

1. html script tag
2. template script tag
3. javascript file

path配置：baseUrl和packages

1. relative path：src
2. absolute path：/xxx/src
3. cdn/static-server url：http://xxx.com/xxx/xxx
4. dynamic: ${path}/xxx

other

loader config在template script tag和javascript file的情况时，path配置与当前文件path不对等，需要映射

这些是否应该进到版本库里？我的理解是module.conf可能需要进，.edpproj不应该进，所以edp是否应该支持加ignore的功能？

以下是我的期待：

整合

可以用edp add命令整合在一起，变成edp add js xxx.js和edp add html xxx.html，这样拥有更高的扩展性，比如未来可以edp add action Xxx，这样code gen也就合在里面了。

扩展

是否可以更好的扩展，与未来的脚手架也整合在一起， add 这个词是很泛用的，感觉有很多东西可以做进里面。

js的模板

建议addjs的模板中的exports改名为调用命令时给的那个文件名，且 如果文件名是大写开始的，产生的文件中对应不是一个对象，而是一个函数 。

这个不用说了，使用tangram的时候，经常会用到它。

请发在这里

周末为edp集成了jshint检测，其中，我把eqeqeq的配置改成了false，理由是：很多时候没必要用===。举两个例子：

下面这种情况，如果明确输入是Array，===是多余的。同理，在我们清楚知道两边类型相同时，===就是多余的。

errors.length == 0

我们有时要利用==的特性。比如我们要判断一个货是否null或undefined，最好最简洁的办法是：

value == null;

开放收集不同意见至周日。

edp-ext名字不是很合适，以后再改，主要目的是放yui.jar, clousre-compiler.jar等其它一些东东。

edp-ext应该是很少修改的，作为edp的一个依赖

初步粗想了下脚手架的需求如下，仅作抛砖引玉用：

目的

脚手架的目的是减少重复劳动，明确他处理的是标准情况，特殊的具体的情况需要自己在生成出来的代码上手编。

生成内容

脚手架生成的代码内容应该要有：
a.模块代码文件(含模块中的列表页/表单页/单字段修改详情页等)
b.控件代码文件
c.mock数据文件
d.前端测试文件
e.控件Demo页
其中a b是主要的。

我觉得脚手架可以提供2个level，1个补充。

level1

根据少量输入(譬如就1个模块名ad)，输出整个模块代码，含列表页、表单页、详情页(单个字段修改页)。这个level面向受众是只想要个代码架子，然后在其上面填码。

level2

根据较多数据输入，生成更为具体的代码文件。
譬如生成1个表单页。
鉴于页面布局和所用class样式基本不会变，唯一变的是各页面的控件不一样。
对于页面控件元素，可以用json来表示，对应当前action的控件树结构，如下：

page: { 
    id: '', //控件ID。key是控件属性，value是控件属性值，借此可拼出控件html片段
    type: 'ui.Panel',
    children: [
    {
        id: '', 
        type: 'ui.TextInput', 
        dom_name: 'name' //控件html片段中的dom属性，用dom_前缀。一般控件的tag是固定，如果可变可相应给个tag配置项。
    },
    {}
    ]
}

我们可以通过这个页面控件json数据 + 一个基础的布局html模板或布局html片段 + action.js模板文件 来生成最终模块代码文件。
进一步地可在json数据中设置控件的一些事件(event_onselect)，脚手架可在输出代码文件中添加该控件事件。
对于开发者来说，只需要看着原型写个控件树的json数据。

控件只是生成最终代码文件的一个配置项节点，此外还需要请求方法配置项requester，列表页的字段配置等，同样可以加入这个json数据文件。单字段修改详情页相比较表单页只是在控件树中多了层ModFrame的描述。

控件代码的生成，分简单控件和组合控件。
简单控件脚手架可以帮忙生成模板文件(或不使用)，控件js代码中的标准API(含示例？)、测试文件、demo文件等。
组合控件脚手架最终应该是图形化的可拖拽，并可点击添加事件(同VS里视图界面类似)。近期简单声明控件组成及相互交互事件？或者干脆同简单控件一样操作，自己手编。

另外1个补充

提供一套模板引擎（2次开发/第三方/全新开发可再评估），可以根据自己定制的模板和变量json文件，快速批量生成代码文件。这个主要面向某一类型页面只出现在单个产品线的情况。

进阶

应该是近阶段不会做的。

• 脚手架配置的图形化。
• 组合控件的图形化操作。

• 希望可以 edp test跑所有的单元测试，可以有一些参数如指定浏览器或者远程类BrowserStack服务更好
• 整合jsCoverage

留着，不急

为了节约命令行标签，一般会edp webserver start . &，但是这样退出就挺麻烦的，所以建议给个edp webserver stop .的功能，可以在start的时候生成个pid文件放在那

Weinre是目前移动端比较通用的调试工具，Adobe Shadow等都是在其基础上开发的，FIS也对Weinre进行了整合。

请 @duanlixin 参考内外网现有的资料，调研Weinre，看看与edp是否有结合点；作为插件整合进edp，能否提高开发效率/降低使用门槛。

收集知识点ing

RT

需要保留JS文件中的空白和注释，类似如下的流程：

a.js -> [JS Parser] -> [JS Serializer??] -> b.js

希望a.js和b.js的内容可以完全一致（空白，注释都需要保留）

在code-gen的阶段可能会用到这些功能。

Fer下面用的是python实现的一个库，不过希望能找到JavaScript实现的库（jshint可能可以）。

锦囊，微购，广告物料项目中大量使用ant和rhino来构建整个项目，按照趋势应该迁移过来。

RT

根据投票的结果，在erik原有的draft的基础上进行了一些修改，还剩一些问题：

• HTML/CSS的注释需要规范吗？
• 不得使用行内样式是否具有确实的可执行性，因为我看到不少项目在写模板的时候，对于仅需要控制显示/隐藏的，会用行内样式style="display: none;"，而且感觉这是合理的，分出去到.css中写反而有点累赘。
• <table>是否强制要求写<tbody>？
• <img>标签包含width和height属性的可执行性，如果图片的大小发生变化，感觉维护起来会很麻烦。

另外，HTML的规范执行远比CSS及Javascript要麻烦很多，更多的是要靠Code Review进行，特别对于标签语义化这一点，除了进行技术分享普及相关知识外，也只能几位负责人在Review的时候多多加强了（特别是轶灵）。

具体见这里

1. Response Header添加必要的字段
2. 支持OPTIONS Method

http://fe.baidu.com/doc/ecom/std/ui/v1.1/

本次讨论内容涉及基础抽象部分。组件部分的标准化工作将在基础抽象部分定稿发布后，挨个进行。

讨论时间：截至下周3(2013-3-6) 0:00

规范中描述的参数命名需要 camel case，而如果是 opt_value 这样的可选参数，本身是不符合 camel case 的。个人认为对这样的特例应该在规范中有明确的描述。比如对于「可选参数，应写为 opt_camelCase」。

建议调整为npm search的效果，否则没屏展示的内容太少。

有时候，代码中有些方法是一个扩展点，会接受几个参数，但默认没实现。

这种函数的参数不能删，为了jsdoc和表示扩展点到底能接受哪些参数，但是由于函数体是空的，所以会被jshint报错。

因此建议把unused配置改为"vars"，不再检测函数参数未使用的情况。

比如这种代码：

xxx.processCustomLogic(a, b, c) {
    // 默认是不做事，等着被重写
}

<项目目录设计规范>规范草案地址为：http://fe.baidu.com/doc/ecom/std/directory.text

讨论时间：

讨论时间截止下周三（2013-2-27）凌晨12点。下周三（2013-2-27）将对有分歧的问题发起投票。
提出问题时间截止周日（2013-2-24）凌晨12点，此时间后不允许提出新的问题，可继续对已提出问题进行讨论发表意见。

请大家踊跃提问题发表意见。

例如

edp minify a.js
edp minify b.css
edp minify c.json

例如：

edp upload a.js
edp upload b.png
edp upload c.swf

上传完毕之后，返回绝对地址即可。对使用者屏蔽复杂的上传过程（可以考虑使用cms和bcs的API）完成这部分工作（类似Fupload.py做的事情）

同时应该提供API供其它地方调用，方便项目部署的时候自动把一些静态资源部署到线上，避免手工做这些事情（类似assets_manager.py做的事情）

草案见这里：

http://fe.baidu.com/doc/ecom/std/3rd-part-app.text

<Package规范>规范草案地址为：http://fe.baidu.com/doc/ecom/std/package.text

讨论时间：

讨论时间截止下周三（2013-2-27）凌晨12点。下周三（2013-2-27）将对有分歧的问题发起投票。
提出问题时间截止周日（2013-2-24）凌晨12点，此时间后不允许提出新的问题，可继续对已提出问题进行讨论发表意见。

请大家踊跃提问题发表意见。

截至今天19：00。

草稿地址为：http://fe.baidu.com/doc/ecom/std/html-and-css-code-style.text

顺便，附上google的html和css code style文档给大家看看。我们参考了一些：
http://google-styleguide.googlecode.com/svn/trunk/htmlcssguide.xml

1. 是否强制要求写thead/tbody/tfoot

   a. 是
   b. 否

2. img标签的width和height属性

   a. 必须（MUST）写
   b. 尽量（SHOULD）写
   c. 允许不写

3. img标签的alt属性

   a. 必须（MUST）写
   b. 尽量（SHOULD）写
   c. 允许不写

4. 内联样式<tag style="......"

   a. 不允许（MUST NOT）
   b. 除控制逻辑相关，比如display:none之类外，不允许（MUST NOT）
   c. 随便写

5. 标签自闭合

   a. 必须（MUST）闭合，且/前必须包含一个空格：<input type="text" name="title" />
   b. 不允许（MUST NOT）闭合：<input type="text" name="title">

6. 表单的name命名

   a. 必须（MUST）camel
   b. 必须（MUST）下划线分隔
   c. 产品线可自己定义，产品线内必须（MUST）保持一致

7. css属性定义时冒号:和属性名之间的空格（此项含义为是否允许多属性声明之间的冒号对齐）

   a. 不允许（MUST NOT）包含空格：margin: 0;
   b. 不做定义，允许包含：margin : 0;

8. url()引用

   a. 不允许（MUST NOT）包含引号：url(background.png)
   b. 不做限制

在未越狱的iOS设备上是无法修改hosts的，为了方便移动端开发，我们需要支持在本机或开发机上搭建DNS服务器，拦截特定域名的请求至本地服务器。

大众点评的 @code4craft 已经写了一个DNS服务器（blackhole）来做这件事情，我们可以将其整合至edp中，给做移动端开发的同学使用。

请 @junmer 调研一下blackhole与edp的整合。

至少把edp config user和edp config email都设置一下，后续经常会用到，尤其是code-gen的阶段。

jshint的增强版，直接修复一些不符合规范的错误。

RT

<Module规范>规范草案地址为：http://fe.baidu.com/doc/ecom/std/module.text

讨论时间：

讨论时间截止下周三（2013-2-27）凌晨12点。下周三（2013-2-27）将对有分歧的问题发起投票。
提出问题时间截止周日（2013-2-24）凌晨12点，此时间后不允许提出新的问题，可继续对已提出问题进行讨论发表意见。

请大家踊跃提问题发表意见。

例如

edp beauty a.js
edp beauty b.css
edp beauty c.json

涉及project相关moduleConfig的处理部分~