选择html还是脚手架作为demo？
一般的客户在刚开始往往不了解自己到底想要什么样的软件，随着项目的一步步进行，他们会根据实际完成的部分逐渐理清头绪，提出进一步的要求。
有一种说法就是，“真正的需求是在第一个版本完成的时候产生的。”用户在看到完整的成品后，才首次理顺了自己的思路，然后在成品的基础上对功能进行删减。
为了让客户更早明确自己的需求，还是应该根据最初的模糊需求制作出一个demo来，为客户提供一个实体做参考，来进一步细化需求，避免前期的返工。这个最初的demo是交付静态html页面还是由grail那种脚手架生成的crud程序呢？
我倾向于使用脚手架生成的动态程序。
第一，脚手架生成的代码，可以模拟基本的动态功能，也可以保证所有的链接都是完整的，添加测试数据可以直接在笔记本上给客户演示。而静态页面会有很多无效链接，对演示和客户体验造成障碍，影响客户输出更详细的需求。
第二，脚手架生成的代码，更贴近程序员，为数据库进行初步建模就可以生成所有的依赖关系，而静态页面更依赖于美工，这里也考虑一个付出的时间代
价，同等量的页面，是自动生成快一些，还是由美工做快。对于crud部分的页面具有很大的雷同性，应该是自动生成更快，这种页面由美工来制作会产生很多无
效链接。
第三，为demo生成代码的数据库建模，还可以为以后细化建模提供依据，而美工做的demo太粗糙，以后改动很大，感觉等于让美工做了无用功，之前demo的部分很少为以后的开发阶段服务。
但，使用生成代码也有缺点，如果使用html，可以直接交给客户，让他们在本机使用。要教客户在本机配置环境运行代码就太难了。只能采取需求人员
带自己机器，陪客户一起操作（是否为客户和需求人员造成不便？）。或者发布到公网服务器上，让客户直接访问公网服务器上的demo进行试验操作。（是否有
安全保密问题？）
以上想法，偏向于局域网内部程序，对美工排版没有很复杂的要求。应该不适合公网项目对页面要求很复杂排版的情况。
冰云
我认为UI，User Interaction和Domain Model是软件设计的两只脚。
只精通其中一种，那设计出的软件也是残疾的。
UI和DM都是对业务功能一种描述，
UI是输入和输出，DM是逻辑处理。
良好的UI和DM都应该有可用性强，美观舒适的的特点。
可用性体现在UI就是布局、操作习惯和便捷程度。
同样是操作系统，为什么linux就不如win普及的多？
体现在DM就是良好的抽象、依赖分离以复用和移植
美观舒适体现在UI就是美术设计，�
相关文档：
用到的MX标签：constraintColumns、ConstraintColumn、constraintRows、ConstraintRow
给大家说说前提情况：在做MXML布局时，要嵌套很多层级，这里面有很多问题：
1、嵌套太多层级会影响效率！
2、嵌套太多层级，代码的可读性、可维护性差！
3、嵌套太多层级是因为Canvas、Vbox、Hbox功能单一，不能满足需要，而不是必� ......
WEB服务器控件是HTML控件的一种扩展,区别是:
1)前者可以触发服务器控件特有的事件，后者只能通过回递的方式触发服务器上的页面级事件。
2)输入到前者中的数据在请求之间可以维护（即具有状态管理功能）,而后者无法自动维护数据，只能使用页面级的脚本来保存和恢复。
3)前者可以自动检测浏览器并调整到恰当的显示，而� ......
根据我最近的一些实践以及在和一些读者进行关于HTML表格的使用问题沟通之后，决定写这篇文章。总的来说，我注意到由于误导性信息，他们对于table的使用有种先入为主的厌恶。事实上很多人会说”我看到永远不应该使用表格”的说法，但是这绝对是错误的！这个建议只是针对使用HTML表格来定义网页 ......
对于HTM网页，加入：
<meta HTTP-EQUIV="pragma" CONTENT="no-cache">
<meta HTTP-EQUIV="Cache-Control" CONTENT="no-cache, must-revalidate">
<meta HTTP-EQUIV="expires" CONTENT="0">
然后，jsp页面中加入：
<%
response.setHeader("Cache-Control","no-store") ......
可以说几乎每个做过Web开发的人都问过，到底元素的ID和Name有什么区别阿？为什么有了ID还要有Name呢?!
而同样我们也可以得到最classical的答案：ID就像是一个人的身份证号码，而Name就像是他的名字，ID显然是唯一的，而Name是可以重复的。
name原来是为了标识之用，但是现在根据规范，都建议用id来标识元素。
以下只能� ......
