4/30/2005

在中国卖的东西很多是垃圾,象那个短信的EMAIL

目前不知葛那里的资料是什么回事,如果没有猜错,其实也没有什么用处的。论坛就是一个jsp较散乱的例子,照顾它改过来花了不少时间。不难,但是花时间。 而且我也在这时侯更感到找不到水平的人帮手是越帮越忙的道理:除非范式互相认同并同达到共同的规范;否则就会蔓延出一大堆乱七八糟的jsp;把它一个个跟 回来固然花时间,而如果不管,那一旦底层组件有修改就不得不照顾版本问题而不得不向下兼容,这又导致要照顾几套版本,滚雪球一样滚大。相反,自已照顾的话 至少可以更熟悉也可以使用工具帮忙。所花的时间常常更少一点。

iframe自动刷新的部分成功地令二级域名等保持了会话;但是保持会话的目的似乎没有达到。还要再进一步观察。今天的论坛仍没有完全跟下来,而且诊室前台部分也没有完全跟妥。

alexa那里退到了7000,这才开始接近正常。而www则由于线程用尽,停了小半小时。还要继续监视。 做一个连接,再看看另一个链接,再看第三个,和第四个,第五,以后就做好一句话,照抄,the Create,jchinamed,另一个blogchina,edu,否酷,歪酷,另一个也不错再加一个。几个简单的全都行了,但是直接拷贝下来的就不行。还是先做好一页,以后全是抄吧。Alexa的计数看来挺操蛋的

4/29/2005

仍未开始继续中断的工作

大约五天前,因为必须先把科室基础转移到数据库,涉及到SectionBase的大迁移;这个大迁移随之又涉及到一个严肃的课题:有关存储对象化和实例化 的问题。SectionBase大迁移牵涉到了所有jsp和标签直至类的包括命名规范化的再整理;以及包括系统后台的大清理,把struts.Acion 向HanvaActionTag的转移;这是一个大扫除,既扫除已知的不规范,又以发现新知的问题,如二级域名会话丢失的问题。以至于五天后,事情才算告 一段落。

早上花了一个多小时,把roleadmin.jsp搞定了。本来原则是如果原来的组管理还可以跑就不作修改,那怕修改是举手之 劳,但是它就是给权限卡住 了。既然是举手之劳,就改掉它吧!的确,对于有权限要求的操作,使用tag较直接显示为url的servlet优越性明显。趁着他们还在上班,先上载到 dep上让他们可以跟进检测一下基本功能。

的确检查了不少事情,大扫除仍没有完全完成,在form中仍有不少flow的不合调用。bbs 就是一个。但在打算到www看看原来的链接是如何产生的,却 发现down了,日志显示是线程用尽,有小半个小时,看来tomcat的问题还是挺多的,(用尽线程就释放重启就是了,为什么会down呢,这条要上论坛 问问)

中午,重新又碰到那种每刷新一次就出现一个会话的情况,而URL重写已经是使用了RL,看来仍不是点。更重要的是,重复性也太差 了。转眼又似乎OK了,似 乎是一旦通过认证产生就可以了。不过,问题正在这个地方,是否认证只不过是一直绑定在session中的visitor的属性,又怎么会影响到会话的认定 呢?进一步的实验表明,是由于经过了真实的域名后就可以绑定会话,否则就不可以。(还是要上论坛问问)。这样也可以解释为什么www上的会话产生会如此之 多了:这是由于每刷新一次产生一个新的会话!最终通过提早嵌入一个无显示的iframe解决了问题,iframe指向一个固定域名的地方。

尽管使用了tag代替servlet优点明显,但在一页中串列一系列处理tag然后再显示的话,然是不行的,主要是不能提供重新刷新的效果。因此,凡是这种处理,还是在弹出页处理最为合理。


做一个连接,再看看另一个链接,再看第三个,和第四个,第五,以后就做好一句话,照抄,the Create,jchinamed,另一个blogchina,edu,否酷,歪酷,另一个也不错再加一个。几个简单的全都行了,但是直接拷贝下来的就不行。还是先做好一页,以后全是抄吧。Alexa的计数看来挺操蛋的

4/28/2005

今天还是扫除和更替为主

做一个连接,再看看另一个链接,再看第三个,和第四个,第五,以后就做好一句话,照抄,the Create,jchinamed,另一个blogchina,edu,否酷,歪酷,另一个也不错再加一个。几个简单的全都行了,但是直接拷贝下来的就不行。还是先做好一页,以后全是抄吧。Alexa的计数看来挺操蛋的,周日到周一明显我是试验性作弊,弄到了2000左右,但是稍后就停了下来,而计数却仍是在2000多,甚至还有上下浮动。可见它的即时性颇为不准。估计有一些平滑性措施之类。还有,我是对着dep作弊的,而这也没有在记录上显示出来。

在 添加上instance和serialz自管理方法后出错,检查下来,发现是由于同一个实体的不同时侯是可以使用不同的Class的;同时,它不 一定总是带有全部的字段(field)方法;因此尽管instance/serializ方法总是存在(继承),但字段不在,仍是留下log记录;因此需 要添加判断:只能是指定的类而不是超类作为读取对象时才进行这种对象的串行处理。
在实际围绕着formtag的测试中产生了缺乏回归性的结果:一开始是没有得到dform,然后围绕着formtag为何没有成功转向做工作,忽然间,一 切都消失了,变成了另一个错误:在初始化实例时没有找到entity. 另外看来把所有相同的文件不因用途不同而分开是对的。

中 午睡了一觉后精神觉得好得多了。不过在重新检查role/member管理时却失了方向,不知道原来是如何实现的,而且老一套似乎根本就不能运 转,那怕是在www服务器上。唯一的办法似乎只能是在下班后他们都不干时把dep的换成旧的对照着操作。在此前,先进行其他,但马上就又发现问题。

实 际上在把转向的域名前缀去掉后,就不时发现有会话丢失的情况。开始以为是密码打错之类,但现在很清楚:在使用非主域名及struts的 action后,按ActionMapping的重定向都造成了会话的丢失。原因是什么,这里仍然没有很明确的认识;估计和中间有一个"/"的过程,在失 去了app路径后会丢失会话,这是经过验证的。但解释并不充分。由于ActionMapping的处理并不是完全透明的,这样,也就失去了进一步解决的可 能。使用非主导的工具体系的缺点也就在这里。可以改写一个同样的tag,看看用Hanva.ActionTag是否会出现同样的情况,或者会有更准确的认 识。这样一来,改写的部分就进一步延展了。在写这个程序前先把entitytaglib和cmdlib分开,由于处理程序越来越集中到taglib中,这 样原来的分类就显得太庞杂了。

然后就改写了那个logonAction为LogonTag,但是在这个程序能够开始工作前,最 终却发现会话仍是丢失了。直到,在改写中使用R,L 而不是L时,才得到修正。看来,这是与是不是struts的无关;而是与非正常域名的改写规则有关系。由于目前没有在首页提供登录,所以没有迹象表明同样 作用到首页,但可能性是非常大的。要维持二级域名全程,看来只能使用R改写。但是进一步显示的结果非常可怕,就是在二级域名改写的情况下,几乎没一次刷 新,都是一个新的会话记录。……但随后这种情况又消失了,显得非常的不确定。这下子也没有办法再进一步了,因此会话显得太不可靠,没有重复性,也就没有什 么可研究的地方了。目前可以做的也就只是知道session可能会丢失,以后在碰到类似问题时可以先查一下。

晚上九 点多了;终于回来重新看那个旧的会员管理为什么可以工作。原因在于Opflow把type传了过去(在这里显得挺巧妙的),这样,尽管form中没有 type,但仍可以令cgi接受type。而现在没有 opflow,就只能让form预备下type了。葛兵,96688-013901310204;

roleadmin.jsp 是最早的一个列表jsp,同时也是最复杂的一个;也是唯一的一个两重列表。简化了要求后,实际上也同时是验证几个处理标 签的正确性。看来,还是应该把几个共同页面归一。明天,仍然需要一定时间继续搞清洁。随着五一假期的到来,不可能期望其他人帮忙了,还是我自已去验证最主 要的功能吧。


4/27/2005

今天是搞代码大扫除,全部规范化

昨晚上已经是注意提早上术睡觉,但是仍然是早醒的毛病,今天的精神状态和昨天差不了多少,仍需要注意休息。博客司机中国博客csdnhanva.testXP编程测试专栏BlogSpot博客城参考站点一参考站点二参考站点三参考站点四参考站点五jakarta中国医疗中国医疗中国医疗协会草珊瑚博客总线CORAR酷网中原人
从日志上可以看到,由于会话保留时间很长,搜索擎带来的会话造成了很大的负担。看来,有必要有一两周内使用iframe保持会话;而把会话保留时间压缩到很短。这样还有另一个对计数上的好处。

今 天的工作内容主要集中在令DAO类型可以对自已的集合字节实行实例化和串行化的管理;这涉及到Section的彻底取消,除了实际上使用 database的section之外;在重新编译所有类的过程中,大量涉及到一些action中的错误;既然要修改action,不如顺路直接改到 tags;改到tags,又涉及到opflow和jsp中的清理,包括struts-config中的清理。这样,就演变成一个根本性的大清洁了;尽管是 早就有计划进行的。从另一个角度考虑,大清洁通常对于后面的维护,包括再开发的起步有实在的好处。象opflow,如果不加以清理的话,实际上已经变得无 法再用了。

写好了VEntity/DAO的实例化/串行化代码,完成编译;把SectionBase的代码彻底清除出去以绝后患;把 Action的代码和 opflow中已经过时的设置全部清除;把jsp中涉及到的连接全部清除;其实真是一个大工作。到晚上才叫完成。但调试却还没有开始;还是先睡一觉再说 吧。

4/26/2005

今天精神不好

自dep升级以后,应该抓紧在五一黄金周以前把它升级到www上,以便有两天可以用来检查实际运行情况。升级到www上还有一个操作就是要确保科室的正常 运转。由于原来的目录是原装备份的,不行就换回来,倒也没有什么不妥的地方。病专栏部分也没有太多的可处理的地方。升级后仍需要把科室设置的xml拷过 来,然后备份一次;因为原来的科室的备注是不全的。不过升级是很容易漏掉东西的,asoka改错改漏未改好的固然如此,而dao.xml中关键的针对服务 器的调整项目也忘记了。不过,现在比当初还是好得多了,只有几个地方要跟进,不然碰到升级就是一堆抓瞎。
这两天精神仍然很不好,今天也是如此。早上起床还觉得不错,但很快地精神就直线下降;而且休息也不管用,浅睡易醒,对噪声敏感;这是积劳疲惫的表现,要注 意休息,特别是提早睡觉,平时累了时能睡就睡,把精神恢复过来,效率就好事半功倍。
目 前是把section等作为对象型放在数据行中,它和关系数据的结构差别在于之与多表关系隐藏中子对象集合之中。对象有集合,而关系数据库就没有这个集 合。通常在关系数据库中类似section-artype这样是以多对多关系表示,通过sql连接。但在显示时仍是麻烦的,那个集合最终仍是不得不面对。 在把section转移到数据库后,一直没有直接修改到这一步,直到发布后就发现了这个问题,这是一个需要静下来理一理的事情。
早上laura在 和chase提了提缺科室的事,不出所料,chase根本没有考虑内在的含义,马上一把否定。这就是我说的业务人员不懂业务建模但又不愿 承认不懂,不愿意承认建模的必要性的表现,回答是预料之中的,(看昨天的记录),如果没有自已的主见,人家说什么就否定什么,那么就什么都不用做了??因 为人家没有义务把事情做出来;也没有提供如何做的解决方案;只是说这个不好那个不好。人家现在不懂也是东西不好的理由之一。几乎是立刻的,原来强烈反对的 科室首页推出,得到了承认??实际上这本来就是网站建设的基本常识之一。
今天实在是疲劳,大约效率只有正常情况下的二分之一以下。尽管出了几份博客,其实不过是工作过程中的思路总结,非此不足以明了下一步如何做才是合理的。也不勉强了,该睡就睡吧。

asoka的任务

昨天布置了asoka几个任务原则和三个具体任务:把诊室搞妥,直接编辑专栏介绍,修改更新标签,减少一次数据库访问。今天再看看代码,前一个没有开始, 中间一个没有搞定,后一个我还没有看。明天要再打个电话问一问,并且还可以再布置另外的几个任务:其一是qzys栏目允许原作者继承发问;其二是前台允许 判断时间显示new;或者包括论坛。他目前的处理方式是挺可笑的:最前四个定为new;回想起早先他的日期处理方式,估计要求它做到按日期处理还不是太容 易呢!基础不足,皮毛不懂,从asp角度理解jsp;不懂英语;提供的余地就很有限。不懂英语,我想是致命伤。明天估计他会开始搞诊室,所以不妨再缓一 天。

我把_jsp目录移到管理目录下面,并把后缀名改成jsp_由于有apache保护,不再担心会给下载到客户本地。这主要涉及到各个 科室的目录中文件也要 改到当前。不过由于asoka的专栏部分还没有改好,这样如果改过来是不是我替他搞掉呢?显示不妥,所以不如继承让他使用旧的_jsp目录,然后在他这个 问题完毕后再一起过来。使用find . -mmin -xxx的办法可以找出修改过的文件,或者这样更有利于保证版本的一致。反而是数据库有修改,要注意保持一致性。

今天全天精神甚差,勉强撑持,眼皮直跳,甚至傍晚睡了一两个小时也没有好转;其实也没有怎么睡,总觉得周围太吵了,睡不觉,似睡非睡的。

4/25/2005

4.25网站的在线统计

网站的统计功能需要一个专门的服务。实际上它的统计包括两个层次的含义:需要日期参数序列的日志,和单一总计的统计。后者分别由各个实体记录中的字段累 计,但无法分清各个时间段的累计。而各个日期段的时间,就不能在实体中记录,否则太复杂了。解决办法就是通过这个专门的服务直接作为汇总报表登记入一个专 门的表之中。这个类更象是另一个log,只不过,只记录点击/时间段等方面的内容,而不涉及其他。所以分析下来,这是一个不小的模块,而且相当复杂的。

网 站的在线统计目前受制于会话时间段;时间段太短不成,但太长也令会话失真。一个办法就是在每一页中添加一个iframe,iframe中使用一个自动刷 新窗口,然后就可以把会话时间收缩到很短,大概只有几分钟。这样的好处除了在线统计真实了许多外,还有另一个好处就是可以借此调整网站的流量。frame 当然可能更好,但我目前真的没有找到无frameset的frame操作的例子,可以再去问问别人,但需要时间。一些网站的排名如果没有这种手段,我才不 相信他们有能力跑到一千几百。

有了这个在线统计,就可以很好地实现在线客户显示等等功能,同时,刷新部分也可以提供另一个功能,就是实时信息提示。总之,还是有必要的。

4.25对这个网站建设项目的初步思考总结

对网站的建设实际上我有着最完整的思路,但Chase总是否定得太干脆而没有经过深刻的考虑(这也是他一向的大缺点),别说laura极少支持或有水平支 持,就算有,其实也没有太大的用处;Chase是除非他自已认识到,否则跟他说什么也没有用的。最后,我现在实在忙得紧,如果没有时间精力马上付诸实行的 话也没有必要现在提太多的东西。如果需要干的话,其实也不见得非要说服chase才去做。这指的是二级层面的工作。

在一级层面上,仍需要 一步步说服chase。相对而言,说服蔡生更容易也更危险:如果他觉得前途困难,他可能干脆就中止了。一级层面的事情,其实就是说整 个网站的思路是否符合小而广的建网原则。违反小而广原则的网站,基本上是不可能获得独立的成功的。这个原则归纳起来,对网站来说就是OPEN的,允许其他 人进来,而不是自已特约的专家才可以进来。实际上,吸引专家的数量是网站成功的关键而不在于那份合同,这是chase没有搞明白的事情。不过,这并没有否 定合同带来的科室建设的稳定性,红花需绿叶,现在需要的是绿叶。chase的思维似乎缺乏处理多层次因素和相互关系,综合考虑的能力,

我 们的架构支持许多的科室建设。唯一例外的就是dabase在基记录太多的时侯,可能需要考虑它的载入方式,分二级载入,或者,象科室菜单等就建立一个机 制,定时载入到一个文本文件中,以减少内存中的记忆量。不过,这条目前还不用太担心,虽然列表打印出来量很多,但并没有迹象表明系统内存在危险边缘。

因此我们应该放开接受科室。另一方面,目前建立的科室有大科有小科,小科居多,这也意味着需要多个科室。多个科室必然意味着科室的导航入口;而这又是目前所缺乏的前台的考虑机制。Chase没有能力去考虑这个问题,而laura则没有意识去挖掘考虑这个问题。

除 了科室,接受外来新的专家显得更重要,这是目前他们的考虑都非常欠缺的地方。象论坛,应该将招引并留住其他专家作为一个重点中的重点,包括专科学生;另 外,象诊室之类应该可以以博客为基础扩展开来。这样,有了基础的资源,其他的业务项目才有生存的余地。这种修改也不需要大的投入,只不过是小的,却是至关 重要的基本逻辑的修改。在这个修改完成前,这个网站实际上并没有贯彻小而广的原则,而是不自觉地多少跑了大而窄的路子。

目前无论是博客还 是黄页登记,或是招聘,都接近于是一个通行证对多个服务;每个服务都带有一个后台管理;一个前台用户管理和一个前台受众浏览的部分。逻辑 相似,就可以建立相似的组件。一个不大不小的问题就是缺乏映子科室的建立。尽管表面上黄页和博客都是附在科室上,但科室开得实在太窄了,我们不可能针对一 个领域百分二十的普通受众建立这个服务。但建立影子科室则面临另一个不定量,就是如何处理影子科室,这涉及到一定的业务策略,这不是我能够处理。目前能够 做的就是削弱科室的影响,建立一个专门的黄页登记前台,把分科不分科的都登记起来;事实上也需要这样一个前页,不过,也必然会受到chase的反对_实际 上是不理解!

象blogger这样的一个通行证可以管理多个专题栏目值得考虑,这样利于专题的建立。不过,不算太利于单个栏目的综合建 设,而且,一般人还是习惯针对一 个栏目建设,而宁愿使用多个ID。允许黄页和博客、招聘发到多个科室可能是有益的,但也会令所有人发到所有的科室,这也不是一个好的办法,倒不如可以让他 改挂进不同的科室。无论如何,黄页等与个人相关的项目还是不要和科室结合得太紧密,而以挂靠的方式为妥。这样,就不涉及到科室的管理,而是在系统管理中进 行;同时,要把这些部分从科室管理菜单中去掉,至少是不能删除;或者说删除挂靠,这是一个很重要的原则。

项目中最困难最矛盾的地方

前一阶段我花了大量的时间到了菜单组排上,这是我极不情愿的。我一直认为自已是一个至少是组件级别的开发者,而不是菜单编排上的开发者。但最终却不得不如 此,而必要性,其后就忘得差不多了,只能要横蛮的态度:就应该这样来应对各人的疑问。现在,我再次面临这样的问题,而原因却深刻地体会出来了,把它记下 来,可能对以后如何处理这种困难矛盾的境地有所帮助。
对于这个问题,首先必须明确,作为网站本身的策划其实是不足的,业余的,尽管商业策划中的一些想法存在闪光点。如果我在公司的收入是满意并有保障的,或者 就不会持完全的支持态度。问题在于,chase本身对于网站建设和推广缺乏基本常识;而又不容易接受他人的专业意见??当然,这是双向的问题,如果他容易 接受他人的专业意见,他很可能就不会同时具备同样高的自信和热情。换言之,名义上chase是销售,实际上只是销售联络员,真正让网站能够销售,却是要靠 我的策划和工作。
大部分时间内,另两个本应发挥更重大和更自觉作用的角色是laura无论是专业水平还是个人投入都很欠不足,这也令这个网站的建设从一开始就存在先天不 足,如果我不加以全力支持,这个网站几乎从一开始就是不可能存在的。而另一个参与者石生,更大程度上只是起到令项目上马的作用而没有对项目本身提供任何实 际的帮助,或者许可证的申请除外,那也是要花专门的精力的。这样一来,实际上决定这个网站项目生死的是我,而不是别人。
从我的角度上来说,尽管辛苦,但把这个网站扶生扶大却是最合乎我的利益的;尽管让它开始从投资角度上看不算太合乎公司的风险控制。一方面,我实际上已经具 备,我个人相信,全中国乃至全世界最强大的网站开发能力,至少就单人来说是这样;而且我相信,即使是许多大公司的开发团队都不会比我一个人更强。我是专家 中的专家,高手中的高手,我自已深信这一点。但初始地位和的机会的不足,特别是在中国这样一个压抑个人的封建国家,我必须抓住身边的每一个机会;而建设一 个大型的专业化的成功的商业网站,既是能力的证明,也是职业能力的提高,成则于公于私都有利,败,至少也可以让我的技术能力再上一层楼。
另一方面,我的年龄先天不足,实际上我开始学程序的年龄是其他人开始退休的年龄,仅仅是靠着一种疯狂,我的一年实践相当于他人的两到三年,而且一直是在技 术的最前沿,不存在老化的问题,这样才使我后来居上,当仁不让,那怕是所谓的高手的所言所谈所做所创,在我分析后,却感到其实比不上我。而我一向自名为德 国人风格,对于发现自已的不足是无情的,对于自已能力的肯定也是不回避的,我相信我的评估是客观真实的。
但年龄的不足就使得我的能力在其他公司获得认可的机会大大降低,实际上根据就没能给我施展的机会。所以这个项目提供了这样的可能:无论它多么不可能,开始条件多么不理想,至少是我可以作重大发挥的项目;可以进一步证明自已的地方。

这就是我其实是最希望这个项目成功的一个人的原因,尽管表面上是帮助chase成功,而实际上帮助他成功,我自已也是不会失败的,反之,如果他失败了,我 也难以成功。难题就在于这里,我不但要维持投资者的信心,还要维持销售者的信心,以及其他同事的信心,而这些伙计的水平又太低,甚至可以说是不学无术,碰 到完全矛盾的致命的概念缺失或错误,我既不能回避,也不能照搬,要让他们能够理解,但又不能让他们太丢脸子,(会丢掉信心的)。
菜单就在程序来说是一件小事,完全可以由低几级的人员去从事,但他反应了一个网站的基本框架是否合理。chase的理解力就停留在菜单上有那几个字,而不 能理解几个字后面是什么概念;laura本来认为菜单是她的天然权力,但她却没有从网站使用者的角度以及这个网站商业可行性去考虑菜单的层次,仅仅是百分 百奴性地牵就需求用户的无知和要求。这就是我不得不直接处理菜单的原因。
就以目前碰到的问题来说:黄页是针对医生的登记,同理招聘和商业发布都是一样的;而chase能够找来的科室只是占了可用科室的20%,难道辛苦做出来的 黄页和商业发布就对20%的科室和医生起作用?简直就是白痴的选择!其实解决办法也很简单,只需要换换思路就可以做到:科室尽管是网站的基础,但只是吸引 人气的信息集合;是发布其他商业的渠道而不是唯一的载体。专家的黄页没有必要一定归属于科室,同理药品和其他也不必归属于科室,它们是独立的。但可以挂到 不同的科室下发布,这时侯,科室是网站发布的服务租凭方。
这是人见人懂的基本原则,但我敢肯定,那哥们就是不懂!而且一旦我提出来,是什么反应我都可以预先知道的:第一就是不理想,多几个字后面的全都是白说,这 样理由再充足也说不来去了;其次,就算是理解了,他也会先否定你的,反正理由嘛正理歪理总是可以找到的;而最大理由就是:我们是和科室签了合同的,离开科 室就失去了特色。多搞几个专项门户在同样的资料基础上发布专项内容,不会影响科室本身的特色,这条,几个月了,他还是不懂。 这就是困难的地方,就算明知前面是对的,还不能先走十足,以先走70%,让他否定,然后再转成90%100%。
菜单是这个逻辑的晴雨板,象如果黄页实际上是不能挂到科室下面的,那么科室下面就一定是少的,不能再分;那么他们落后的理解能力就难以理解为什么想象中的 省市分类不存在??别人都可以做到为什么你不能做到?却不去看别人的科只是一些分类,而我们的科室却是营业的实体;别人的分类可以单纯地做得完全,我们的 科室却只是一部分。
如果象黄页不属于科室,(可以挂靠),那就必然需要一份黄页入口的首页,黄页,最典型的就一定是从首页开始导入的。但这样他们,特别是chase不会说,这相当于多一个站,好了现在他已经糊涂了,到时更糊涂,所以不赞成。
这就是我最困难的地方,实际上对于眼前要做的东西,这帮家伙没有一个准主意,但却都执着某一方面反对的死理。我却必须把几个抽象的想象的东西,一般是做一 个可以B2B买卖药的网站,变成一个实际可以运行的实体,业务也是可以运作的;已经够困难的了,还要面对这些个死理,有些还很无聊的,象laura:看见 下拉菜单就别扭??您是专业人员,怎么把自已的喜欢代替从客户角度的考虑?我不是喜欢下拉菜单或讨厌,但我要求所有专业人员都必须从专业角度出发,从客户 眼光出发考虑技术问题,而不是任由自已的喜好,这是非常缺乏职业质素的表现。
今天我仍是如此做,把基本的东西做出来,先不在前台显示出来,然后让他自已说出我要做的,这样就少点反复了。