再谈东方之门建设进展照片之Gallery

鉴于上篇讲到了照片展示,拿了别人的照片,总要介绍下自己用来做什么,不然觉得心不安。

用于实现gallery的代码不少。有javascript的也不乏flash的。相关的介绍与汇总google下会有不少,比如:33 Most Beautiful Javascript and Flash Galleries20 Best jQuery Slideshow / Photo Gallery Plugins等。javascript代码框架(例如JQuery)一般都实现了更基础的一些代码,比如滑块、鼠标滚动等等,因此许多开发者比较喜欢基于现有代码框架来实现gallery。相比于完全从零实现的gallery,我认为常用的框架里对于交互操作的代码实现会相对更稳健,后期维护也更具延续性。

基于上述考虑,我选了几个作了候选,其中一个是3D-Wall-Gallery,一个基于JQuery实现的javascript photo gallery。支持滚动、缩略图、滑块拉动等效果。我比较喜欢它的一个重要原因是它实现了照片的预加载,也就是不用在每次切换照片时都有一个停顿感。现在用户的体验要求越来越高,一个loading…符号并不能让用户满意,最好就是不需要等待!照片按时序排列并辅以时间标签,当然,拖动滑块和选中缩略图时的交互体验还可以做得更进步一些。下面是效果图。

基于3D-Wall-Gallery实现照片展示
基于3D-Wall-Gallery实现的照片展示

html实现部分可以有多种方式,例如我的照片是这样组织的:

因此在具体实现时,我使用javascript动态创建<li>标签。当然,后台动态代码来实现,亦可。

实际效果参考3D-Wall-Gallery的例子

Ext JS中TreePanel的级联操作

版本:Ext JS 3.3.1

一直用很怪异的方式去遍历TreePanel的节点,例如在深度关系>2时总是要展开某个非叶子节点,然后才能获取到下面的叶子节点。

今天写一个uncheck所有节点的功能时,才真正尝试这种级联操作,毕竟少了ui上的展开操作,效率还是要高一些。下面是代码:

Flex嵌入到HTML后切换焦点不能输入中文的解决方案

快要下班时,听康康一言,又突发奇想了若干关键词百度了下,找到了vipliyaohua的一篇博文。经过试验,困扰了已久,真是郁闷郁闷郁闷加憋屈至极的问题终于得以解决。

博文地址:Flex嵌入到HTML中切换焦点不能输入中文和遮盖DIV的问题

作者指出了两个问题,解决了2个问题:

  1. div被flash嵌入对象遮挡,这个问题在实现div下拉式菜单或浮动元素时经常遇到。关键方法是设置wmode=“transparent”或”opaque”。此非重点。
  2. flash嵌入html后,html元素不能正常使用中文输入法。之前找了很久的原因,把问题锁定到了IE下flash+html的某个bug(Firefox下正常),但一直没能解决。

引用 vipliyaohua的问题描述:

我们突然发现当焦点置于Flash后再切换到HTML元素中 如HTML的INPUT输入框中,不管怎么切换我们的输入法,中文就是出不来。

经我反复测试,基本如上描述,当然操作上并不绝对。比如:有时候来回变换焦点后输入法并不会被直接禁用,会有延时。至于输入法,是可以成功切换,但是中文输入操作被禁用。

当然,这不影响解决方案的有效性:在鼠标移开flash对象时强制设置输入法功能开启。以下参考原文中提供的事件绑定例子。

 

使用autoLoad将html文件内容加载到Ext.panel

使用javascript框架有一点比较郁闷,尤其用Ext JS:使用了框架提供的布局,就很难全身而退。往容器里加载Html页面经常是不二之选。下面的例子使用autoLoad实现:

如果panel自身也是动态加载到layout之中,则由于容器渲染时并不知道页面的宽度与高度,因此无法只适应大小,应在该容器渲染之后根据实际情况设置其高度:

加载Html还可以在Ext.panel的html中添加,类似这样写:

此法问题在于,单独的iframe无法自适应高度。
当然,也可以用update。

Ext技巧-BorderLayout不可以动态修改布局怎么办

Ext版本:3.3.1

应用场景:在一个one-application-one-page模式的系统开发过程中,页面布局使用了borderlayout,用到了top,east和center。但是某些特别的需求需要在中央区域显示静态html内容。首先想到的就是移除center处和east处的panel,然后重新进行页面布局。无奈怎么修改都未能实现。其间之怪异问题层出不穷。

网上有许多关于此的讨论,例如:

讨论1讨论2讨论3讨论4

Ext JS官方文档中(Ext.layout.BorderLayout)有关于此的一段话:

The regions of a BorderLayout are fixed at render time and thereafter, no regions may be removed or added.The BorderLayout must have a center region, which will always fill the remaining space not used by the other regions in the layout.

大致意思是该布局的region不可以被动态(在渲染完成后)添加或删除。

参考官方Layout FAQ中关于为BorderLayout添加项目的建议论述,以及讨论4中的观点。采用了变通的方法,修改布局,将center处容器修改为accordion布局,将原center中的panel作为该容器的一个item,通过动态修改accordion的item(或其属性)来实现目的。

既然是替代方案,自然可以多种多样,此仅一例。

总结一下:

就题而论,所谓layout,本就变化无穷,稍微多一层嵌套,并无大碍。

讲大了去,不用太执着,实现不了的东西,不要将“理论上成立”作为坚持实践的依据。

IFrame布局——失败选择

关于技术分歧,我从来不想陷入孰是孰非的口水战,因此对于iframe和div,一直都抱着各有优缺点的态度去旁观,自认为客观而公正。最近的项目很赶,由于ext3.x风格修改较为麻烦,因此计划尽量少用ext作为外观设计,只使用其逻辑功能。美工同志设计了iframe架构我边直接拿来用,认为凡事都可以适应。无奈多个多个frame的存在导致脚本代码的重复加载,并且该问题难以彻底解决。网上有一些解决方案,主要是两类:

  1. 分解js代码。如果是自由代码,这也许可以成为解决方案,但割裂整体性的结局未必会让人觉得使用起来可以驾轻就熟。
  2. 父页加载js,子页通通使用父页的js代码。这原本是不错的方案,但是无奈dom操作与子页元素密切相关。使用parent或者window.top来获取父页的js功能不仅代码累赘而且dom逻辑极易混乱。

许多努力和时间已经花费在当前的结构上了,修修补补也许还是可以继续完成工作,割舍真的很难。但是考虑到这样的问题延伸到以后都会十分痛苦,毅然决定推倒iframe方案,改用ext的布局与autoLoad加载多页的模式,改起来也算是得心应手,顺利的多。于是开始思考,为何在架构之初隐约感觉到了js重复加载的问题有可能存在,为何没有先下手尝试解决这个问题,这样可以早点发现难处到底有多难。

正确的做事顺序还是应当坚定地坚持,刚开始多花费了一些时间,也许就会少走一点弯路。正如华莱士·史蒂文斯所说:选择决定了结果。

在一件事情的发展过程中我做出了许多选择,这些选择的成败不在于选项是否正确,而在于是否选择让让它变成那样。有时候我们选择一个东西正是因为清楚它的优缺点,但它确实刚好合适。如果没有搞清楚这些,即便最优秀的选项,也可能是一种错误。

反思之架构能力

急于求成的时候事情到手便干,快速解决问题。来公司之初经常处于这样的状态,有时候没有办法,事情很赶。等做了一堆东西,回过头来看的时候,还是一盘散沙。主要有这样几个问题:

  1. 散沙很难聚起来形成整体
  2. 任务很难分割
  3. 更换人手时不易上手,维护带来困难
  4. 缺乏文档,说明设计思路是非常费劲

其实架构上的工作一直在推进,只是不系统,通过完成独立项目的过程中来更改不合适的部分。之后因为时间紧迫和惰性发作的双重效果,缺乏系统的总结。今天讨论到了这个问题,就做了几点思考,觉得架构上的工作需要系统地完成。

  1. 快速学习
  2. 敏锐观察
  3. 精通业务
  4. 及时自省
  5. 沟通协调
  6. 宏观把握

这些关键词还远不够全面形容架构所需。

说人的能力有限不如说时间有限,如何避免时间分散是我要关注的另一个问题,抵抗新鲜技术和兴趣领域的种种诱惑比抵抗金钱的诱惑更为困难。总之,把握有限时间,补充必要知识,锻炼架构能力。

Skyline与伟景行的几点比较

近几个月使用skyline和伟景行(CityMaker)两个三维平台做了点应用案例,两者差异明显,总结几个不完整的感受下来:

  1. 沟通方便程度。skyline是国际上知名的产品,在国内由东方道迩代理。虽然有了国内代理,但是在商业推广以及销售和支持上貌似还做的很不够;相比下,伟景行是国内产品,销售和支持相对完善方便。也许东方道迩挺冤:软件不是他们写的,真的能懂的不多。
  2. 性能。这是关注最多的点了,网上对比已经不少了。我没有做过非常严谨地测试。但是在我所做的范围内,Skyline5.1.3无论跟CityMaker6.x还是4.x,在性能上都是不可比。Skyline的场景浏览是建立在大量模型简化和纹理压缩的基础之上,对于整个场景的数据量有这非常苛刻地控制。相比下,CityMaker做规划三维出身,对于场景效果优化比较在行,可以支持数据量较大、较为精细的大场景浏览。
  3. API。这方面,Skyline比伟景行要早,要成熟。CityMaker的API现在功能还不够丰富和完整,但是可以算是稳定。Skyline的API较为完整,尤其是B/S下的开发应用,比CityMaker要具有更大的用户基础。要说优势的话,就是CityMaker在国内,技术支持真的很方便,API遇到的问题可以很快解决,甚至因为还没有成型,用户可以提出需求,伟景行会考虑你的建议对API作出修改。
  4. 更新。CityMaker当然要更勤快些,这可以理解。国内竞争?上市?但是Skyline的更新之慢确是不能理解,也许官方对自己的产品非常地有信心。
  5. 市场保有量。没有做过统计,但是Skyline吃市场的能力是很惊人的,绝对不能忽视。尤其是政府单位的自上而下效应,Skyline可以很轻易地吃掉一大片。相对,伟景行这方面还需要较长时间地积累。但是随着三维应用逐渐摆脱“花瓶”的角色,一切都在改变,未来还是个未知数。
  6. 价钱。一切竞争从模仿做起,真的,伟景行模仿skyline很严重,包括价格。

暂时总结这几条,在三维领域还不太专业,只是些感受而已。:)

Ext容器里放Flash Object时要注意的

You can disable expand/collapse animation by setting animCollapse:false in the panel config.
The slideIn/Out animation used by expand/collapse temporary relocates the element inside a absolutely positioned wrapper. The DOM relocation sometimes kills the Flash object in IE.
You can disable expand/collapse animation by setting animCollapse:false in the panel config.
The slideIn/Out animation used by expand/collapse temporary relocates the element inside a absolutely positioned wrapper. The DOM relocation sometimes kills the Flash object in IE.