为什么我今天想到“程序员与博客”这个立题，主要还是源于前几天自己的某个博客被封杀，当时很是纳闷。java眼居然说我的文章玷污他们的神地，我很纠结，很郁闷，很崩溃。写了这么久的博客，居然落得这步田地。纵然是文章烂，你也别封杀我啊，搞得我像凤姐一样——臭名昭著、丢人现眼。

　　牢骚发完，进入主题。我今天想说的是程序员与博客的那点事情，不为别的，只希望如我一般的程序员们，应该多写些博客，多散发下自己的内心。别一天尽是class，package，function，produrce，那样的生活多少有些枯燥、无味，时间一长，人也会变得呆滞难看，细想起来总是有些不值。世界本就如此精彩，何故一味地钟情code。

　　我也是最近爱上写博客，以前基本上不写，这样的转变主要还是源于空聊无寂的生活。一个人，孤孤单单生活在深圳这个大都市里——迷茫，渺小，无助。寂寞之于，我开始写博客。慢慢的，我发现写博客是一件令我愉悦的事情，既打发了那些空荡的时间，又能在博客中广交朋友，每每看见自己的文章获得别人的点击，赞同，短评，总是蹈足欢腾。写博客能到这样的程度，多少算是有点痴。

　　我从不敢妄想自己的文章是佳作，可终究都是自己的言语。拿出来不怕丑，秀一下不怕臊，显一下不怕鄙。

　　写了这段时间的博客，我今天只想把自己写博客的丁点想法奉献给大伙。奔着三个问题求证而来，好与不好，不吝赐教。

　　第一问，程序员为什么写博客

　　程序员为什么写博客?不为别的，只为感触生活、分享心得、丰富人生。

　　何为感触生活，说白点就是知道自己活在世上，我有很多同事，他们总是习惯于冥坐在电脑前，除了敲就是打，整天一门心思只有对技术的迷恋。有时真不知道他们这样子图个啥。古人云：以有限的生命，去追逐无限的知识，岂不可怜。这里告诉你，作为程序员的你我，别一味地除了代码还是代码，技术永无止境，生命稍纵即逝。何况写代码也并非易事，光勤不行，得有悟道。代码写乏了，提起笔，写篇博客发散下自己的感悟，畅快之于，可能你又可以领悟到另一种新知也未必，何乐不为之？

　　在程序的世界里摸爬滚打这些年，我们总会钟情于某个方面，沉迷于上，研究入深，久而久之，多少能知道些别人不解的东西。倘若如此，你千万别把它们看似宝贝的压箱底，其实知识也如人一样般，终有无用的一天，这样的宝贝收藏无益，何不拿出来和大伙分享。没准能得到高人指点，使其更上一层楼；又或者觅的知音，一同说道说道，也不枉今朝一时。

　　在前面的一篇文章中，我说程序员多少有些自闭，有人不同意。可就我看来，身边的很多同事每逢休息，总是一个人呆在家里，上网，聊天，游戏，就是这样的生活——单调，乏味，枯燥，腻！以其这样荒诞地打算青春，何不提起笔，刷刷两下，发泄出内心的牢骚，写写自己的工作，感悟下奋斗的人生。待到人老珠黄的那天，不时间拿出来看看瞧瞧，也会感慨一番——年少轻狂，此生无悔。
　　第二问，程序员该怎么写博客

　　“该怎么写？”，“想怎么写就怎么写”，这就是答案。博客本就是消遣娱乐之举，无须太多修饰，唯有朴实，纯真，有血有肉，足也。

　　好几次，博客里的朋友总是问我，为什么不喜欢写技术类的文章，我总是轻笑着答到，“不会写，写不好”。有时想想，在软件堆里混了这些年，皮了，累了，油了。技术对我来说已经变得无趣，无聊。所以我现在几乎不写技术类的文章，偶尔兴趣所致，也就是拿自己的框架，叨咕上两句，草草了事。也许你会笑我轻狂，无知，我不回避，因为我本就不是那类技术痴人，何故自欺欺人，捉弄自己。

　　想怎么写就怎么写，不要在乎别人如何看，如何品，哪怕就是一句简单的 System.out.println(“hello world”)，那也是自己的感，自己的误——真实，可信。
　　第三问，程序员博客写什么
　　喜欢写博，自然经常在各博客里面打转，就软件类专业博客，我喜欢去的无非就是csdn，java眼，以及现在喜欢的博客园，blogjava。不过这次java眼是让我很郁闷，所以我开始唾弃它，也就懒得去了。
　　相比之下，就博客内容而言，我觉得博客园相对好点，确切的说是专业些，不过我还是想提点意见，有时太过专业也未必是件好事。毕竟程序员是人，总是有七情六欲的，不能一味地要求大伙写的东西都往软件上靠，这样多少有点狭隘。在我看来，不管你是技术研讨，软件工程，项目管理，开源框架，文学小说，诗歌散文，都应该有权利，有机会发表。丰富方显多姿，聚类总能完美。

　　在博客园里，发表纵然是没问题，可推荐到首页就有点麻烦。前几天我的小说，就是被这样无情地抹杀了，虽不是什么好文，起码短短10分中就得到了500多的点击，况且严格来说它属于程序人生的范畴，发表到这里，总能有些共鸣。可无情的管理员还是把它从首页踢出了，有点伤心。鉴于我对博客园的一点好感，也默许了这样的结局。不过我最终还是希望管理员们思想开阔些，因为我们的程序员都是有血，有肉，有情，有感的正常人，自然时常也是会说，会笑，会哭，会跳。

　　“一篇好的文章应该如一坛佳酿，未偿已久醉于心；或如一壶好茶，品尝之间回味无穷；或如与心爱的人共进晚餐，仅餐秀色足以饱食。我不妄想自己的文章能惊世骇俗，但始终期待有‘和旋之音，击缶之伴’”，这是我的杜撰，很希望有同感的程序员们如此对待写博。平平淡淡，真真切切，写出真我。

　　 说到MVC团队组合模式，那就要说说我的框架WMframework，

　　 WMframework现阶段采用主要技术有：s2,ibtatis2,spring3，HTML，js， xml，ajax，整个技术框架也是自己杜撰出来的，一直自己在默默地喜欢着，改进着，这些年的程序员生涯也就剩余这点东西可以怀念下了。我向来不是吝啬的人，所以在后面的时间里我会逐步把自己的WMframework拿出来与大伙分享，希望有心的你可以期待，当然更梦想得到大伙的真知灼见。今天我主要说的东西还是我的团队中如何使用MVC团队组合模式进行软件开发。
　　 MVC团队组合模式？
　　何谓“MVC团队组合模式”，主要意思就是把一个团队里面的各成员按其个人综合技能进行分工协作，具体地说就是针对每个业务模块的开发，采用各成员进行分工协作完成的模式。一个模块，张三完成一部分，李四完成另一部分，王五又完成其他部分。这有别于大伙常见的由一个人承担某个模块的开发合作模式。

　　 先来说说我们常见的开发模式。大伙都知道，我们通常的软件系统开发中，很多时候都是这样的，先由项目经理或小组长做统一的任务分配，把具体的各功能点模块按人头分配给团队中的各程序员们。比如用户注册张三负责；组织机构管理李四负责；哪天哪天这个模块由谁完成，哪天哪天这部分由谁实现。整个编码计划就是这样指定下来，直到系统的所有功能模块都被分摊到相应的开发人员身上。等待我们的程序员把各模块都编码完成，大伙再把这些代码、功能进行系统的整合、集成、测试等，这就是大家常见的甘特图模式，也是我们通常碰见的开发模式。
　　 我提出的MVC团队组合模式，区别于上面最大的不同就是，我把任何一个业务模块开发任务分为3部分，由三类不同角色的人员来共同完成，这三类人员我称它们为MVC，即M_actor 模型执行者、V_actor 视图执行者、C_actor 控制器执行者。

　　 下面我给出这三者的主要描述：

　　 M: M_actor 模型执行者

　　 主要任务：后台业务处理模型，主要就是Dao，sqlmap的编写；（在WMframework中，我已经弱化了dao这层，因为在WMframework中我们的dao都是公共的，开发人员基本上不用写dao。）

　　 个人要求：要求开发人员对数据库操作能力强，对整体业务流程充分了解，保证其sqlmap编写的sql完成当前模块的业务需求。

　　这部分可以由擅长数据库开发人员和需求分析人员结合完成。
　　V：V_actor 视图执行者

　　主要任务：前台表单视图，主要就是jsp，html，js的编写；完成页面数据表单的设计、实现、业务数据的js校验、提交等。（在WMframework中，我对于页面表单数据提交、校验也是一个公用的自定义js前台框架，开发人员只需要写简短的几句js脚本调用即可。）

　　 个人要求：开发人员需要有很好的UI设计能力，可以更为人性化地实现页面操作，使其有更好的用户体验，知道些js语法和html标签使用即可。

　　 这部分由美工、UI技术人员和需求分析人员结合完成。

　　 C：C_actor 控制器执行者

　　主要任务：s1/s2中的action，业务层接口service的编写；

　　个人要求：开发人员熟悉常用的java开发模式，有很好的java开发能力，能很好地处理request请求，respronse返回响应等。（在WMframework中，我同样弱化了action的使用，很多时候对于多数页面请求只需要调用公用的action即可，开发人员基本上不用自己写）。

  　 这部分资深java开发人员完成。

　　 MVC团队组合模式优势

　　 通过我的介绍看出些好处没有？很明显，若采用MVC的开发模式来在组织团队人员，对不同类型的人员要求就不尽相同。
　　 C_actor 可以完成不用了解系统业务，他们只需要关心如何解析前台提交的请求数据，就WMframework而言就是完成从request里面读取xml转化为bean(这里说的bean也就是我们常说的pojo、vo、bo等)的实现；然后通过外部接口service转交给内部实现dao，最后在dao中完成持久层的相关操作；
　　 V_actor 可以完全不用了解什么叫j2EE，只需知道jsp的表头怎么写（其实很多时候不用写，因为我们都是include进来的嘛），合理地设计页面表单的布局，知道哪里该放button，哪里该用text，哪里摆个textarea，哪里该弄个select等，仅此而已；
　　 M_actor不需要关心用户界面如何设计，该怎么制作，用户数据以什么方式提交。他只需要清楚当前业务涉及那些数据模型，各数据表中相应的字段是否填上，哪些是必填项，数据类型是什么，数据大小如何定义，数据存储是否正确等。
　　 如果联系到公司人员配置问题，这里也有一点优势在里面。因为很多时候，很多公司，总会在项目来临一味扩招，项目结束一味削减，而最终能保留下来的也就是那么几个核心人物，当然我这里不是提倡这样的作法，毕竟多少有些凶残。如果你的公司，你的项目采用了我说的MVC团队组合模式开发，那很多时候，你的核心开发人员、业务人员依旧全力地支撑着整个项目，他们掌握着整个项目的核心，所以很多时候，你可以重点培养M_actor与C_actor，对于V_actor自然多少有些微不足道，弃之无妨。不过做人起码需要些厚道，尽管商场残酷，商人无情，终究我们都是人，应该多一点感情，多一点良知。实在不想要他们了，能最大限度给点补偿也不枉人家为你卖命一场。
　　 以上这些就是我能看到的基于MVC团队组合模式开发的优势，使用它可以让我们的开发人员减少许多需要关注和学习的东西，有时候闷头想来做一个合格的java web开发者，你最基本的可能需要知道这些：java、jsp、js、xml、css、sql、ide、html等，太杂，太多，太烦。但如果你使用如上所说的开发模式，让开发者专注于各自所特长的一方面，并进行很好地发挥，最后更好地完成自己的任务，做好自己喜欢的工作，那种感觉应该会好很多。起码是辛苦并快乐着，哈哈。。
　　 MVC团队组合模式劣势
　　 前面竟说了些好听的，下面我来说说MVC团队组合模式的弊端，最明显的一点就是，各类型成员间开发任务的同步性、顺序性、可用性测试、问题跟踪等。比如一个用户基本信息维护模块，如果某天客户需要增加一个用户生日的信息，必然会涉及 C_actor进行业务数据对象修改,M_actor修改sqlmap中的insert,select,update等语句，V_actor 修改表单jsp增加生日的输入框等。又或者用户基本信息业务模块出现异常（数据不正确，不能保存等）也必然需要C_actor、M_actor、V_actor来配合完成跟踪，这自然也就增加了当前任务消耗的资源。再或者用户基本信息业务模块不能在规定的项目计划时间完成，其最终的责任应该算在谁的头上。C_actor说用户表单没有设计，如何完成action的编写，V_actor抱怨数据模型没有给出如何知道页面元素类型，哪些应该必填，哪些应该选填，哪些应该下拉，哪些应该只读，我都不知道，叫我如何设计页面；M_actor呢，咆哮V_actor页面表单都没有，叫我如何知道业务模型需要那些字段，需要什么样的数据类型，需要多大长度。最终是个个推诿，人人有理，整天就是这样缠绕在彼此间借口的闭环中，周而复始、无穷无尽。哎，程序员，难啊。。。。。

　　 凡事皆有两面性，对于MVC团队组合模式我基本上说的差不多了。我曾经在一些项目中使用过它，有说好的当然也有暴跳骂娘的，终究是孰是孰非，谁对谁错，我也不得知晓，只待各位自己去想，去悟。

安装配置的详细步骤可以参考官方的用户手册：http://www.family168.com/tutorial/jbpm4.0/html/installation.html

最新发布的jBPM-4.4中解决了108个issue，不过它距离上次发布也半年有余了，jBPM-4.3发布于2009年12月底。

jBPM-4.4是一个bug fix版本，并未对数据库有任何修改，使用之前版本的项目基本可以平滑升级。在进行升级时需要注意：

1.Activity和Transition两个接口从org.jbpm.pvm.internal.model包下移动到了 org.jbpm.api.model包下。
2.所有与el表达式相关的部分都替换为新加的org.jbpm.pvm.internal.el.Expression。

添加的几个重要功能：
1.for each支持动态的并发分支流程，会签和并发子流程都可以用它来实现了。
2.assign活动，可以对变量的值进行复制。
3.变量声明，可以在xml里声明变量。
4.修正了console在tomcat下找不到dataSource的问题（包括报表）。

详细的发布信息，请参考官方的JIRA：https://jira.jboss.org/secure/ReleaseNote.jspa?projectId=10052&version=12314183

用Alejandro的话说，This makes 4.4 the most cat-friendly jBPM yet!下个版本会对数据库结构进行修改了，以便完善流程历史库的功能。

相关的发布下载与文档资源如下：
Subversion tag: http://anonsvn.jboss.org/repos/jbpm/jbpm4/tags/jbpm-4.4/
Maven artifact: http://repository.jboss.org/nexus/content/repositories/releases/org/jbpm/jbpm4/jbpm/4.4/
SourceForge file: https://downloads.sourceforge.net/project/jbpm/jBPM%204/jbpm-4.4/jbpm-4.4.zip

User Guide: http://docs.jboss.com/jbpm/v4/userguide/html_single/
Developer Guide: http://docs.jboss.com/jbpm/v4/devguide/html_single/
Maven Artifact: http://repository.jboss.org/nexus/content/repositories/releases/org/jbpm/jbpm4/jbpm/4.4/

另附我们翻译的用户手册和开发指南：
用户手册：http://www.family168.com/tutorial/jbpm4.0/html/index.html
开发指南：http://www.family168.com/tutorial/jbpm4devguide/html/index.html

如何改善SQL语句的一些原则：
1. 按需索取字段，跟“SELECT *”说拜拜
字段的提取一定要按照“用多少提多少”的原则，避免使用“SELECT *”这样的操作。做了这样一个实验，表tblA有1000万数据：
select top 10000 c1, c2, c3, c4 from tblA order by c1 desc  用时：4673毫秒
select top 10000 c1, c2, c3 from tblA order by c1 desc用时：1376毫秒
select top 10000 c1, c2 from tblA order by c1 desc 用时：80毫秒
由此看来，我们每少提取一个字段，数据的提取速度就会有相应的提升。但提升的速度还要看您舍弃的字段的大小来判断。
另外，关于“SELECT *“的问题，可以参考这篇文章：
http://www.cnblogs.com:80/goodspeed/archive/2007/07/20/index_coverage.html
2. 字段名和表名要写规范，注意大小写
这一点要多注意，如果大小写写错的话，虽然SQL仍然能正常执行，但数据库系统会花一定的开销和时间先要把您写的规范成正确的，然后再执行SQL。写对的话，这个时间就省了。
正常的：    select top 10 dteTransaction, txtSystem_id from tblTransactionSystem
不小心的：select top 10 dtetransaction, txtsystem_id from tbltransactionsystem
3. 适当使用过渡表
把表的一个子集进行排序并创建临时表，有时能加速查询。它有助于避免多重排序操作，而且在其他方面还能简化优化器的工作。例如：
 SELECT   cust.name，rcvbles.balance，……other   columns    
  FROM   cust，rcvbles    
  WHERE   cust.customer_id   =   rcvlbes.customer_id    
  AND   rcvblls.balance>0    
  AND   cust.postcode>“98000”    
  ORDER   BY   cust.name
  如果这个查询要被执行多次而不止一次，可以把所有未付款的客户找出来放在一个临时文件中，并按客户的名字进行排序：    
  SELECT   cust.name，rcvbles.balance，……other   columns    
  INTO   temp_cust_with_balance    
  FROM   cust，rcvbles    
  WHERE   cust.customer_id   =   rcvlbes.customer_id    
  AND   rcvblls.balance>0    
  ORDER   BY   cust.name    
  然后以下面的方式在临时表中查询：    
  SELECT   ＊   FROM   temp_cust_with_balance    
  WHERE   postcode>“98000”    
临时表中的行要比主表中的行少，而且物理顺序就是所要求的顺序，减少了磁盘I/O，所以查询工作量可以得到大幅减少。注意：过渡临时表创建后不会反映主表的修改。在主表中数据频繁修改的情况下，注意不要丢失数据。
4. 别在where条件中做函数计算
这样做的后果是将在每个行上进行运算，这将导致该列的索引失效而触发全表扫描。如下SQL：
select * from users where YEAR(dteCreated) < 2007
可以改成select * from users where dteCreated <‘2007-01-01’，这样会使用针对dteCreated的索引，提高查询效率。
5. IN（NOT IN）操作符与EXISTS（NOT EXISTS）操作符
有时候会将一列和一系列值相比较。最简单的办法就是在where子句中使用子查询。在where子句中可以使用两种方式的子查询。如下：
第一种方式使用IN操作符：
Select a.id from tblA a where a.id in (select b.id from tblB b)
第二种方式使用EXIST操作符：
Select a.id from tblA a where exists (select 1 from tblB b where b.id = a.id);
用IN写出来的SQL的优点是比较容易写及清晰易懂，这比较适合现代软件开发的风格。但是用IN的SQL性能总是比较低的，而第二种格式要远比第一种格式的效率高。从SQL执行的步骤来分析用IN的SQL与不用IN的SQL有以下区别：
SQL试图将其转换成多个表的连接，如果转换不成功则先执行IN里面的子查询，再查询外层的表记录，如果转换成功则直接采用多个表的连接方式查询。由此可见用IN的SQL至少多了一个转换的过程。一般的SQL都可以转换成功，但对于含有分组统计等方面的SQL就不能转换了。
第二种格式中，子查询以’select 1’开始。运用EXISTS子句不管子查询从表中抽取什么数据它只查看where子句。这样优化器就不必遍历整个表而仅根据索引就可完成工作（这里假定在where语句中使用的列存在索引）。相对于IN子句来说，EXISTS使用相连子查询，构造起来要比IN子查询困难一些。
通过使用EXIST，数据库系统会首先检查主查询，然后运行子查询直到它找到第一个匹配项，这就节省了时间。数据库系统在执行IN子查询时，首先执行子查询，并将获得的结果列表存放在一个加了索引的临时表中。在执行子查询之前，系统先将主查询挂起，待子查询执行完毕，存放在临时表中以后再执行主查询。这也就是使用EXISTS比使用IN通常查询速度快的原因。
同时应尽可能使用NOT EXISTS来代替NOT IN，尽管二者都使用了NOT（不能使用索引而降低速度），NOT EXISTS要比NOT IN查询效率更高。
6. IS NULL 或 IS NOT NULL操作（判断字段是否为空）
不能用null作索引，任何包含null值的列都将不会被包含在索引中，因为B树索引是不索引空值的。即使索引有多列这样的情况下，只要这些列中有一列含有null，该列就会从索引中排除。也就是说如果某列存在空值，即使对该列建索引也不会提高性能。
任何在where子句中使用is null或is not null的语句优化器是不允许使用索引的。
推荐方案：用其它相同功能的操作运算代替，如a is not null 改为 a>0 或a>’等。另外还设置字段不允许为空，而用一个缺省值代替空值，如一个datetime字段，可以将默认时间设为“1900-01-01”。
7. > 及 < 操作符（大于或小于操作符）
       大于或小于操作符一般情况下是不用调整的，因为它有索引就会采用索引查找，但有的情况下可以对它进行优化，如一个表有100万记录，一个数值型字段A，30 万记录的A=0，30万记录的A=1，39万记录的A=2，1万记录的A=3。那么执行A>2与A>=3的效果就有很大的区别了，因为 A>2时sql会先找出为2的记录索引再进行比较，而A>=3时sql则直接找到=3的记录索引。可结合非聚集索引一起考虑。
8. LIKE操作符
LIKE 操作符可以应用通配符查询，里面的通配符组合可能达到几乎是任意的查询，但是如果用得不好则会产生性能上的问题，如LIKE ‘%5400%’ 这种查询不会引用索引，而LIKE ‘X5400%’则会引用范围索引。因为索引的摆放是依据字段值升序或降序排列，like’%*’这种用法，不能利用有序的数据结构，利用二分法查找数据。一个实际例子：用YW_YHJBQK表中营业编号后面的户标识号可来查询营业编号 YY_BH LIKE ‘%5400%’ 这个条件会产生全表扫描，如果改成YY_BH LIKE ’X5400%’ OR YY_BH LIKE ’B5400%’ 则会利用YY_BH的索引进行两个范围的查询，性能肯定大大提高。
9. 查询条件中的适当与不适当
查询参数可以包含一下操作：=、<、>、>=、<=、BETWEEN、部分like。其中，like当这样使用时会用到索引：like ‘*%’,但like’%*’就用不到索引。
不适当的查询参数有：NOT 、!= 、<>、 !>、 !< 、NOT EXISTS、 NOT IN 、NOT LIKE等，还有一些不当的用法，例如：对数据进行计算，负向查询、等号左边使用函数、使用OR。上述语法都不用不上索引，降低程序的效率。

步骤2：添加LinkButton。

二、弹出窗口
给大家的建议：对于这种弹出窗口，它本身的代码会非常的多，所以尽量不要写在application代码里面。而是应该尽量通过自定义的方式来创建组件。

步骤3：将CSS文件编译成swf文件。
二、添加多套皮肤。
对于多套皮肤，通常会有多个images文件夹，而且这些文件有可能是相同文件名。
这个时候，可以在images文件夹下面不同皮肤的图片文件夹。

当使用不同皮肤的时候，在显示上面会有很大的不同，所以这个时候大家一定注意去修改它们。直到看不出明显的显示差距。Panel {
borderStyle: solid;
borderColor: #d5610d;
borderAlpha: 1;
roundedBottomCorners: true;
cornerRadius: 10;
headerHeight: 55;
backgroundAlpha: 1;
highlightAlphas: 0.44, 0.08;
headerColors: #d5610d, #d5610d;
backgroundColor: #73715c;
dropShadowEnabled: true;
shadowDistance: 0;
shadowDirection: right;
titleStyleName: "panelTitle";
titleBackgroundSkin:Embed(source='images_carbon/panel_bg.png', scaleGridLeft=12, scaleGridRight=13, scaleGridTop=30,scaleGridBottom=31);
}
/* Panel titleStyleName*/
.panelTitle {
color: #ffffff;
fontSize: 20;
fontFamily: "Handwriting - Dakota";
}
做皮肤替换功能，主要注意三点。
第一点：要将图片文件分开存储，不要混乱。
第二点：要将CSS文件编译成SWF二进制文件。
第三点：由于不同皮肤在显示上面区别很大，所以大家要尽量将影响外观的差异最小化。尽量只要看到一些不同的颜色，样式，布局不能有太大的变化。

@font-face {
fontFamily:"Verdana";
src: url("fonts/verdana.TTF"); /* Embed from file */
}
使用微软雅黑，替换代码为如下。
@font-face {
fontFamily:"WRYH";
src: url("fonts/msyh.ttf"); /* Embed from file */
}
在替换皮肤以后，发现确实好看了很多，但是这套皮肤并不是为我们程序专门设计的，所以他在很多地方的显示是不尽人意的。这个时候就需要我们去改写。

问题一：面板标题栏文字太大。

步骤2：添加一个DataGrid，用来显示所选择的菜单。










步骤3：添加测试数据。


红烧排骨
1

15.8

白米饭
2

1.0

设置DataGrid的数据源。

步骤4：添加订餐表单。
















二、在首页面板上显示菜单列表。
步骤1：创建一个TileList（平铺列表）。

步骤2：添加测试数据。





















步骤3：添加图片信息。

[Bindable]
[Embed(source="submenu/20090912172231.jpg")]
public var submenu1:Class;
[Bindable]
[Embed(source="submenu/20090912171819.jpg")]
public var submenu2:Class;
[Bindable]
[Embed(source="submenu/20090912172407.jpg")]
public var submenu3:Class;
]]>

将图片设置到TileList中。

]]> http://column.ibeifeng.com/ibeifeng/20100619391.shtml/feed http://column.ibeifeng.com/jk1234/20100619389.shtml http://column.ibeifeng.com/jk1234/20100619389.shtml#comments Sat, 19 Jun 2010 04:59:00 +0000 jk1234 http://column.ibeifeng.com/?p=389 第二讲：前台主界面设计
一、项目的创建
一、首先,建立一个FLEX PROJECT,应用服务器选择J2EE。
二、选择new进行应用服务器的配置,FLEX WAR FILE选择下载的ds-console.war文件
三、点击”完成”,建立好后的项目如下所示:
其中flex_src是Flex的源文件目录,src即是我们所熟悉的Java源文件目录.
四、为项目添加WEB支持以便能直接进行部署。

OK,最后完成后项目如下:
五、Output folder URL设置，在默认情况下，会打开http://localhost:8080/BFOrder/这个路径，但是我们编译的文件在bin目录下，所以需要将其修改成http://localhost:8080/BFOrder/bin，这样就可以了。
直接运行项目，或者运行BFOrder.mxml，如果出现如下界面，表示你的项目已经成功搭建好了。

二、自定义设计区域大小
自定义一个设计区域大小，宽度为1012，高度为600，这样在1024*768分辨率下会有最好的显示效果。

三、创建导航栏
步骤1：拖放一个LinkBar。

步骤二：拖放一个ViewStack。

步骤三：在ViewStack中插入面板。

一共添加七个，分别如下。
首页
餐店简介
美食分类
订餐指南
会员中心
订单查询
我要建议

步骤四：设置LinkBar的数据源。

步骤五：为所有的面板添加标题。

步骤六：调整位置和大小。

四、创建公告栏
步骤1：创建公告面板。

步骤2：创建一个DataGrid。

步骤3：添加测试数据。

本店开张了
2010-3-1

本店开张了
2010-3-2

本店开张了
2010-3-3

本店开张了
2010-3-4

本店开张了
2010-3-5

设置DataGrid的数据源。

]]> http://column.ibeifeng.com/jk1234/20100619389.shtml/feed http://column.ibeifeng.com/ibeifeng/20100618387.shtml http://column.ibeifeng.com/ibeifeng/20100618387.shtml#comments Fri, 18 Jun 2010 15:55:17 +0000 北风 http://column.ibeifeng.com/?p=387 原理很简单，IE下可以通过document.selection.createRange();来实现，而Firefox（火狐）浏览器则需要首先获取光标位置，然后对value进行字符串截取处理。不多说了~直接上我写的一个jQuery在光标位置插入内容插件吧~

Query在光标位置插入内容插件代码

(function($){
$.fn.extend({
insertAtCaret: function(myValue){
var $t=$(this)[0];
if (document.selection) {
this.focus();
sel = document.selection.createRange();
sel.text = myValue;
this.focus();
}
else
if ($t.selectionStart || $t.selectionStart == ‘0′) {
var startPos = $t.selectionStart;
var endPos = $t.selectionEnd;
var scrollTop = $t.scrollTop;
$t.value = $t.value.substring(0, startPos) + myValue + $t.value.substring(endPos, $t.value.length);
this.focus();
$t.selectionStart = startPos + myValue.length;
$t.selectionEnd = startPos + myValue.length;
$t.scrollTop = scrollTop;
}
else {
this.value += myValue;
this.focus();
}
}
})
})(jQuery);
用方法
$(selector).insertAtCaret(”value”);

]]> http://column.ibeifeng.com/ibeifeng/20100618387.shtml/feed