云引擎 webHosting 文档修改

* 时区问题只在 node 文档介绍，因为只有 node 有历史遗留问题。
* Java 运行环境补充项目启动部分的描述。
* 更新一些环境变量的名称。

Author: sdjcw

model.coffee

@@ -36,7 +36,7 @@ exports.getBlocks = (tmpl, impl) ->
   return blocks
 
 exports.getVars = (tmpl, impl) ->
-  varRe = /{%\s?set\s+(\w+)\s?=\s?["'](.*)["']\s?%}/gm
+  varRe = /{%\s?set\s+(\w+)\s*=\s*["'](.*)["']\s*%}/gm
   content = fs.readFileSync(
     path.join(__dirname, 'views', "#{tmpl}-#{impl}.md"), {encoding: 'utf-8'})
   vars = []

views/leanengine_webhosting_guide-java.md

@@ -21,7 +21,38 @@
 ```
 这样云引擎部署时会打包生成对应的 war 包。
 
-如果你需要进行本地调试，可以通过在 pom.xml 中增加 jetty plugin 来本地运行项目。具体的配置你可以参考我们的[实例代码] (https://github.com/leancloud/java-war-getting-started/blob/master/pom.xml)。
+如果你需要进行本地调试，可以通过在 pom.xml 中增加 jetty plugin 来作为 Servlet 容器运行 war 包，具体的配置可以参考我们的 [示例代码](https://github.com/leancloud/java-war-getting-started/blob/master/pom.xml) 。但这样并不能直接使用类似于 `mvn jetty:run` 来启动应用，因为云引擎应用启动需要一些 [环境变量](#环境变量)，否则无法完成初始化。
+
+以下有几种方式可以本地启动：
+
+#### 命令行工具
+
+命令行工具 [v1.3.2](https://github.com/leancloud/avoscloud-code-command/blob/master/changelog.md#v132) 及之后的版本支持云引擎 Java 应用的本地启动，并为 JVM 进程设置需要的环境变量，在项目根目录执行 `lean up`，根据提示输入 `appId`，`masterKey` 等信息，命令行工具会调用 `mvn jetty:run` 来启动应用。
+
+**提示**：相对于其他启动方式，命令行工具有 [多应用管理](leanengine_cli.html#多应用管理) 功能，可以方便的切换不同应用环境。
+
+#### 使用 Eclipse 启动应用
+
+首先确保 Eclipse 已经安装 Maven 插件，并将项目以 `Maven Project` 方式导入 Eclipse 中，在 `Package Explorer` 视图右键点击项目，选择 `Run As` -> `Maven build...`，将 `Main` 标签页的 `Goals` 设置为 `jetty:run`，将 `Environment` 标签页增加一些列环境变量和相应的值：
+
+* LEANCLOUD_APP_ENV = development
+* LEANCLOUD_APP_ID = {{appid}}
+* LEANCLOUD_APP_KEY = {{appkey}}
+* LEANCLOUD_APP_MASTER_KEY = {{masterkey}}
+* LEANCLOUD_APP_MASTER_KEY = 3000
+
+#### 命令行设置环境变量启动
+
+可以使用类似下面的命令来启动应用：
+
+```
+LEANCLOUD_APP_ENV=development \
+  LEANCLOUD_APP_ID={{appid}} \
+  LEANCLOUD_APP_KEY={{appkey}} \
+  LEANCLOUD_APP_MASTER_KEY={{masterkey}} \
+  LEANCLOUD_APP_MASTER_KEY=3000 \
+  mvn jetty:run
+```
 {% endblock %}
 
 {% block ping %}
@@ -96,7 +127,7 @@ Java 云引擎只支持 1.8 运行环境和 war 包运行
 			<artifactId>leanengine</artifactId>
 			<version>0.0.1-SNAPSHOT</version>
 		</dependency>
-        </dependencies>
+	</dependencies>
 ```
 
 * 初始化：在正式使用数据存储之前，你需要使用自己的应用 key 进行初始化中间件：
@@ -145,7 +176,7 @@ EngineRequestContext.getRemoteAddress();
 {% block get_env %}
 
 ```java
-String env = System.getenv("LC_APP_ENV");
+String env = System.getenv("LEANCLOUD_APP_ENV");
 if (env.equals("development")) {
     // 当前环境为「开发环境」，是由命令行工具启动的
 } else if (env.equals("production")) {
@@ -174,19 +205,21 @@ if (env.equals("development")) {
 
 {% block code_upload_file_sdk_function %}
 
+```
 @WebServlet("/upload")
 @MultipartConfig
 public class UploadServlet extends HttpServlet {
 
-   @Override
-   protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
+  @Override
+  protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
     String description = request.getParameter("description"); // Retrieves <input type="text" name="description">
     Part filePart = request.getPart("iconImage"); // Retrieves <input type="file" name="file">
     String fileName = filePart.getSubmittedFileName();
     InputStream fileContent = filePart.getInputStream();
     // ... (do your job here)
+  }
 }
-}
+```
 {% endblock %}
 
 {% block cookie_session %}

views/leanengine_webhosting_guide-node.md

@@ -323,3 +323,45 @@ if (NODE_ENV === 'development') {
 }
 ```
 {% endblock %}
+
+{% block section_timezone %}
+## 时区问题
+
+因为某些原因，云引擎 2.0 默认使用的是 UTC 时间，这给很多开发者带来了困惑，所以我们着重讨论下时区问题。
+
+比如有这样一个时间：`2015-05-05T06:15:22.024Z` (ISO 8601 表示法)，最后末尾的 `Z` 表示该时间是 UTC 时间。
+
+上面的时间等价于：`2015-05-05T14:15:22.024+0800`，注意此时末尾是 `+0800` 表示该时间是东八区时间。这两个时间的「小时」部分相差了 8 小时。
+
+### 时区问题产生的原因
+
+很多开发者在时间处理上会忽略「时区」标志，导致最后总是莫名其妙的出现 8 小时的偏差。
+
+【场景一】某开发者开发的应用使用云引擎的主机托管功能做了一个网站，其中有时间格式的表单提交。某用户使用浏览器访问该网站，提交表单，时间格式为：`2015-05-05 14:15:22.024`，注意该时间没有「时区」标志。因为这个时间是浏览器生成的，而该用户浏览器上的时间通常是东八区时间，所以该业务数据希望表达的时间是「东八区的 14 点」。
+
+该时间 `2015-05-05 14:15:22.024` 提交到服务器，被转换为 Date 类型（JavaScript 代码：`new Date('2015-05-05 14:15:22.024')`）。因为云引擎 2.0 使用的是 UTC 时间，所以该时间会被处理为 `2015-05-05T14:15:22.024Z`，即「UTC 时间的 14 点」。导致最后获得的时间和期望时间相差了 8 小时。
+
+解决上面的办法很简单：时间格式带上时区标志。即浏览器上传时间时使用 `2015-05-05T14:15:22.024+0800`，这样不管服务端默认使用什么时区，带有时区的时间格式转换的 Date 都不会有歧义。
+
+【场景二】从数据库获取某记录的 `createdAt` 属性，假设值为：`2015-04-09T03:35:09.678Z`。因为云引擎默认时区是 UTC，所以一些时间函数的返回结果如下：
+
+函数|结果
+---|---
+`toISOString`|2015-04-09T03:35:09.678Z
+`toLocaleString`|Thu Apr 09 2015 03:35:09 GMT+0000 (UTC)
+`toUTCString`|Thu, 09 Apr 2015 03:35:09 GMT
+`toString`|Thu Apr 09 2015 03:35:09 GMT+0000 (UTC)
+`getHours`|3，如果将 getHours 的结果返回给浏览器，或者作为业务数据使用，则会出现 8 小时的偏差。
+
+如果需要获取小时数据，解决办法是使用第三方的组件，比如 [moment-timezone](http://momentjs.com/timezone/)，通过下面的方式可以获得东八区的小时时间：
+
+```javascript
+var time = moment(obj.createdAt).tz('Asia/Shanghai');
+console.log('toString', time.toString());
+console.log('getHours', time.hours());
+```
+
+### 云引擎 2.0 和云引擎时区的差异
+
+为了方便大家的使用，更加符合通常的习惯，云引擎运行时环境（无沙箱的 Node.js 环境和 Python 环境）都是使用**东八区**作为默认时区。当然，我们仍然建议程序的时间字符串带有时区标志。
+{% endblock %}

views/leanengine_webhosting_guide-php.md

@@ -259,7 +259,7 @@ PHP 云引擎暂不支持其它版本。
 
 {% block get_env %}
 ```php
-$env = getenv("LC_APP_ENV");
+$env = getenv("LEANCLOUD_APP_ENV");
 if ($env === "development") {
     // 当前环境为「开发环境」，是由命令行工具启动的
 } else if ($env === "production") {

views/leanengine_webhosting_guide.tmpl

@@ -17,6 +17,7 @@
 - [Node.js](leanengine_webhosting_guide-node.html)
 - [Python](leanengine_guide-python.html)
 - [PHP](leanengine_webhosting_guide-php.html)
+- [Java](leanengine_webhosting_guide-java.html)
 
 ## 项目约束
 
@@ -221,49 +222,7 @@ ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA5EZmrZZjbKb07yipeSkL+Hm+9mZAqyMfPu6BTAib+RVy
 
 **注意**：日志单行最大 4096 个字符，多余部分会被丢弃；日志输出频率大于 600 条/分钟，多余的部分会被丢弃。
 
-{% block section_timezone %}
-## 时区问题
-
-因为某些原因，云引擎 2.0 默认使用的是 UTC 时间，这给很多开发者带来了困惑，所以我们着重讨论下时区问题。
-
-比如有这样一个时间：`2015-05-05T06:15:22.024Z` (ISO 8601 表示法)，最后末尾的 `Z` 表示该时间是 UTC 时间。
-
-上面的时间等价于：`2015-05-05T14:15:22.024+0800`，注意此时末尾是 `+0800` 表示该时间是东八区时间。这两个时间的「小时」部分相差了 8 小时。
-
-### 时区问题产生的原因
-
-很多开发者在时间处理上会忽略「时区」标志，导致最后总是莫名其妙的出现 8 小时的偏差。
-
-【场景一】某开发者开发的应用使用云引擎的主机托管功能做了一个网站，其中有时间格式的表单提交。某用户使用浏览器访问该网站，提交表单，时间格式为：`2015-05-05 14:15:22.024`，注意该时间没有「时区」标志。因为这个时间是浏览器生成的，而该用户浏览器上的时间通常是东八区时间，所以该业务数据希望表达的时间是「东八区的 14 点」。
-
-该时间 `2015-05-05 14:15:22.024` 提交到服务器，被转换为 Date 类型（JavaScript 代码：`new Date('2015-05-05 14:15:22.024')`）。因为云引擎 2.0 使用的是 UTC 时间，所以该时间会被处理为 `2015-05-05T14:15:22.024Z`，即「UTC 时间的 14 点」。导致最后获得的时间和期望时间相差了 8 小时。
-
-解决上面的办法很简单：时间格式带上时区标志。即浏览器上传时间时使用 `2015-05-05T14:15:22.024+0800`，这样不管服务端默认使用什么时区，带有时区的时间格式转换的 Date 都不会有歧义。
-
-【场景二】从数据库获取某记录的 `createdAt` 属性，假设值为：`2015-04-09T03:35:09.678Z`。因为云引擎默认时区是 UTC，所以一些时间函数的返回结果如下：
-
-函数|结果
----|---
-`toISOString`|2015-04-09T03:35:09.678Z
-`toLocaleString`|Thu Apr 09 2015 03:35:09 GMT+0000 (UTC)
-`toUTCString`|Thu, 09 Apr 2015 03:35:09 GMT
-`toString`|Thu Apr 09 2015 03:35:09 GMT+0000 (UTC)
-`getHours`|3，如果将 getHours 的结果返回给浏览器，或者作为业务数据使用，则会出现 8 小时的偏差。
-
-如果需要获取小时数据，解决办法是使用第三方的组件，比如 [moment-timezone](http://momentjs.com/timezone/)，通过下面的方式可以获得东八区的小时时间：
-
-```javascript
-var time = moment(obj.createdAt).tz('Asia/Shanghai');
-console.log('toString', time.toString());
-console.log('getHours', time.hours());
-```
-
-### 云引擎 2.0 和云引擎时区的差异
-
-为了方便大家的使用，更加符合通常的习惯，云引擎运行时环境（无沙箱的 Node.js 环境和 Python 环境）都是使用**东八区**作为默认时区。当然，我们仍然建议程序的时间字符串带有时区标志。
-
-{% block introduceCloudCodeV2 %}{% endblock %}
-{% endblock %}
+{% block section_timezone %}{% endblock %}
 
 ## 绑定独立域名