注册 登录

自由的旅行

发表于: 2009年4月8日  所属分类: 生活随笔

关键字: , ,

生活中的我是一个怕麻烦的人,不太愿意花时间去思考计较一些琐事之事。可唯独旅行,我有着极大的兴趣去计划,而不会图省事随意跟个旅游团。幸运的是我身边也有很多会玩,并且很Open的朋友,例如小严、沈楠、丁儿等等,很多时候我只需要做个参与者就行了,因为他们会把计划做得非常详细。

很怀恋大学时候的旅行,一帮人没钱,但依然玩得很开心。现在回想起来,那个时候的开心并非是因为旅行中的风景、名胜,更多应该是旅行的自由和刺激。我记得有一次全班组织从南京去滁州琅琊山,我已经不记得当初是因为什么动机有人提议逃火车票,最终是全班人集体逃票从南京进站,从滁州出站,当时班上很多女生的那种忐忑不安和兴奋的表情现在我还能依稀回忆起来。还有一次我们八个男生在旅行中临时决定去凤阳、蚌埠转一圈,之前没有任何计划,当时就是走一步是一步的心态。用光头的话说就是"我是流氓,我怕谁"。虽然我们谁也不是流氓,不过互相壮壮胆倒是可以的。以至于后来八个人跟旅店老板订房谈价格,最终我们8个人在凤阳40块钱住了一晚设备齐全的标准间。在韭山洞溶洞风景区里点菜吃了顿饭,8个菜一个汤,算上米饭,总共吃了46块钱,因为我们没有用菜单,所有的菜都是我们到厨房选料跟师傅当面"讨论"价格的,也造出了不少新菜。在狼峡迷谷为了逃票,差点准备围着山转悠一圈找入口。毕业以后我看《与青春有关的日子》的时候,突然引起了我的共鸣。剧中那帮五、六十年代的人去去广州淘金时发生的一系列事情,最初我觉得相当荒唐和混乱,但想到我们旅行中发生的那么多事情,我顿时又会觉得很真实,虽然年代不同,但我们都曾年少无知过,而正是这种年少无知,甚至是磨难,才能让人更多得懂得生活的意义。

我大学的唯一遗憾就是没能利用更多的机会去自助旅行,小严和沈楠倒是跑了不少地方,婺源、宏村、三清山等等,都是我想去转悠的地方。工作以后,大家的时间就更难凑到一起了,这次也算是机会难得,我和沈楠都有假,于是计划了海南七日自助游,可惜的是小严缺席了,于是乎,当我们躺在椰林的吊床上,看着蓝天白云,吹着海风的时候,我们还不忘记刺激下在公司加班的他。

全程是沈楠幸苦查好的行程,但是我们前往第一站东郊椰林的时候就遇到了小意外。我们从到达文昌已经是下午快6点了,没有考虑到这个时候已经没有去东郊的公交车了。当我们一人背一大包出现在车站门口的时候,顿时摩的都涌了过来,一阵"嘘寒问暖",都是还听不大懂的方言,大概意思就是现在没有车去东郊了,只有坐他们的车把我们送到码头,然后坐小船去东郊。又有商店老板说那种小船晚上很危险。盘算了一下,我们就准备改计划,在文昌住一晚,第二天再去东郊,那样虽然错过了看日出的计划,但毕竟安全重要,现在已经没有大学时候那种肆无忌惮的心态了。那一帮摩的还是很坚强地跟在我们后面,后来一个摩的师傅的说法让我们顿时迷糊了,他说现在还有车去码头,劝我们不要坐那些摩的。于是我们就发愁了,这到底听谁的呢?摩的司机自己要我们不要坐摩的,难道给我们下个套,等我们去码头不成?后来一咬牙拼了,先坐公交杀到码头,如果走不了就在码头住下,明天赶早去东郊椰林。

到了码头已经是快8点了,下车一看,一片漆黑。码头上遇到一个船家说送我们过去,结果我们一看船,就一小木头船,再一看码头下的水,2米之外什么都看不到,更别说岸在哪儿了。权衡了一下觉得太危险了,我们还是决定在码头住下了。转身没走几步,听到一个MM跟跟船家打听去东郊的船,我们一听口音像是当地人,既然当地人这个时间都敢坐这船,那这船坐着应该安全。于是我们又折回去跟那MM打听了一下,最终决定三个人一起坐船过去。当船离开码头以后才知道,那MM是海南人,但并非文昌当地人,她也是第一次坐这船,如果不是有我们两个男生,她也不敢坐这船。这样一想,我们都觉得刚才发生的事情太戏剧了。之后又是船家叫车来码头接我们到椰林湾,实际上到椰林湾已经快晚上10点了。如果不是遇到那个摩的师傅,那我们不会到码头。如果不是遇到那个"当地"MM,那我们不会夜里坐船。如果不是遇到这个船家,那我们即使到了对岸也没有车载我们去椰林湾。太多的假设了,不过很幸运的是,我们最终还是抵达了东郊椰林。虽然椰林的人说日出很难看到,但我们第二天还是5点起床到海边守候了,而我们十分幸运的看到了海上日出,算是给海南之旅开了个好头。

东郊椰林日出 东郊椰林 

一路上大的行程都没有变化,小的路线都是随时调整。原本我们计划从文昌到安宁,然后从安宁前往分界洲岛,后来坐车的时候发现途中经过分界洲岛,于是上演了一幕下车横穿高速路的情景,然后又上演了一幕高速路拦车的情景。在三亚的第三天遇上暴雨,我们几个就犹豫是否要取消去锦母角徒步的计划。最终我们还是冒雨坐上了安游的车,幸运的是我们抵达安游时没有下雨。不幸的是遇上锦母角军事管制,虽然我们穿过了两道军事禁区,最终还是没能抵达最南端的锦母角灯塔。不过后来在锦母角下找了个不错的地方潜水、晒太阳也还不错,更戏剧化的是,当我们离开锦母角的时候安游开始下暴雨了,而抵达三亚时,已经是雨后的晴天。

高速风景

锦母角

旅行途中我用手机在网上更新了条状态"实践证明会一门方言是很有用的"。这就不得不说沈楠那小子"复杂"的背景。他是宁夏人,姥姥姥爷是河南人,于是他小时候在河南呆过几年,而爷爷奶奶又是湖南人,所以他小子向来"多变"。

情景一,当我们在大东海找旅馆的时候,碰巧那间旅馆只剩下一间房,而且是别人已经订过了。正在老板犹豫之际,沈楠那小子听老板和老板娘说话是河南话,于是几句河南话下来就攀上了老乡,老板立马决定房间给我们了。我们故意推辞了一番之后,很为难地说我们有4个人,还需要一个标准间啊。房间是没有了,最终老板居然同意我们4个住一个标准间,房价不变。老板还说"如果我这都不让你们住4个人,那别的地儿更不会让你们住4个人"。

大东海 大东海

情景二,我们在大小洞天玩的时候,第二天去蜈支洲岛的路线和门票都还没有着落了。后来等车的时候遇到两个包车的的哥,咨询了一下包车的价格,我们觉得不太合算,因为我们有5个人,一辆车不够,两辆车浪费。后来闲聊但那的哥老家是哪儿的,有个的哥居然是湖南的,沈楠那小子摇身一变又是湖南人了,当时我差点都笑喷了。最终我们谈妥了,5个人包了一辆车,而且蜈支洲岛门票和潜水的门票给我们弄到一个很可观的折扣价。 所以说,出门在外会一门方言是多么重要啊。这也让我想到那个老鼠学狗叫吓走猫的笑话,最后的结论是"学会一门外语是多门重要"。

在家都没有逛过菜市场的我,在三亚却一起逛海鲜市场,全都是新鲜的海鲜,每天选上个几样,然后找个地方加工一下,再来两扎菠萝汁、芒果汁,一顿丰盛的海鲜晚餐就搞定了。其中有个搞笑的插曲,我们买了几个海胆,后来才知道买的海胆不肥,完全做了海胆鸡蛋羹的餐具。

这也是我喜欢的自助旅行的魅力所在,自由自在,完全可以采用旅行者的处事方式,众多不定因素中会夹杂着惊喜,但前提是同游的人有思想准备,需要灵活地克服不利因素,不要轻易就沮丧了,否则就没有享受旅行的兴致了。

分界洲岛  蜈支洲岛

发表评论 »  ( 8 条评论 )

JQuery1.3升级的变化

发表于: 2009年2月13日  所属分类: JavaScript

关键字: ,

JQuery目前已经发布到1.3.1版本,但1.3.1版只是对1.3版存在的部分bug进行了修正,没有功能上的变化。

JQuery1.3的升级主要是内部实现的改变,重写了此前存在效率瓶甄的方法。官方的测试结果表明,1.3的性能有了很大的提高,主要表现在选择器、事件绑定、DOM动态修改、offset方法的偏移量计算和动画。具体如下:

  • Sizzle Selector Engine

JQ1.3中CSS选择器已经单独分离出来,命名为Sizzle JavaScript Selector Library,并启动了一个新的项目,目的在于联合主流的框架开发者来参与开发,让框架的选择器使用更统一、更高效。目前已经有Prototype, Dojo, Yahoo UI, MochiKit, and TinyMCE等等加入此项目开发。

  • live Events

Event对象中增加了livedie两个方法,支持了对新增元素的事件"自动绑定"。

  • jQuery Event Object

新的Event对象更接近W3C的标准,浏览器的兼容性更好。

  • HTML Injection Rewrite

HTML插入方式(例如append, prepend, before, after)大范围重写。在复杂的jquery程序中,HTML插入效率是一个很大的瓶甄。1.3版本重写了内部实现,提高了这些方法的运行效率,但此前的API没有更改。

DOM创建方法的变化:

$("<script/>")等同于$("<script></script>")

  • Offset Rewrite

Offset 方法重写,目的在于提高此方法的效率和浏览器的兼容性。

  • No More Browser Sniffing

浏览器特性的判断,这是1.3版中最大的一个改变。传统的做法是对客户端浏览器的类型和版本做探测,然后针对不同浏览器做代码的兼容。一旦浏览器升级或者解决某些BUG,就可能造成某些特性的改变,造成此前我们的JS代码不兼容。



阅读这篇文章的其余部分 »

发表评论 »  ( 2 条评论 )

解决IE6下select遮盖问题

发表于: 2008年12月24日  所属分类: JavaScript, XHTML

关键字: , ,

CSS为我们提供了z-index属性来控制DOM元素在浏览器中的层级关系,理论上,我们可以随意设置元素的覆盖关系,但在IE6下,无论我们怎么设置z-index,都无法使用DIV遮挡住select元素,这一Bug困扰了很多前端开发人员。例如之前我做弹出层的时候,在IE6下我不得不将可能出现"冲突"的select元素做额外的隐藏/显示工作,虽然不会影响程序的使用,但细心的用户肯定会觉得这一处理很怪异。

除了我上面提到的程序主动隐藏"冲突"的select元素的解决方式,我们还可以将显示内容装入到一个iframe中,iframe是可以遮挡住select的。但我个人觉得这样处理比较麻烦,所以多数时候我还是宁愿选择第一种解决方式。但现在有个好消息是,我找到了一种更优雅的方式。首先你可以查看示例(解决IE6下select遮盖问题)。

上面示例中有两个显示按钮,点击"非JS处理显示"的按钮,我们可以看到我上面描述的IE6下的Bug,DIV被select遮挡了。而点击"JS处理下显示"的按钮,我们可以看到没有被遮挡。

此解决方式的原理是,在页面创建一个大小、位置和蓝色边框容器一致的空的iframe,并让此iframe的z-idnex位于蓝色边框容器之下。我猜测这可能跟IE6下元素渲染有关系,你可以尝试下将创建的iframe的位置和蓝色容器的位置形成一定的偏差,你会发现只有iframe和蓝色边框容器相交的地方才不会被select遮挡,区域之外的依然被遮挡(你会看到select有一半遮挡,一半不遮挡的奇妙现象)。

下面提供一个JQ的plugin来完成此操作,如果你不使用JQ,根据上面的原理,自己动手也很容易。

  1. ;(function($){
  2.     $.fn.extend({
  3.         fixZindex : function(options){
  4.             return $(this).each(function(){
  5.                 var $this = $(this);
  6.                 var _this = this;
  7.                 //ie6
  8.                 if($.browser.version=="6.0"&&$.browser.msie){
  9.                     //hide
  10.                     if(options == "hide"){
  11.                         $this.prev("iframe").remove();
  12.                         $this.hide();
  13.                         return;
  14.                     }
  15.                     //show
  16.                     $this.fixZindex("hide");
  17.                     var $iframe = $("<iframe src='about:blank'></iframe>").insertBefore($this);
  18.                     $this.show();
  19.                     var _pos = $this.offset();
  20.                     $iframe.css({
  21.                         width:$this.outerWidth(),
  22.                         height:$this.outerHeight(),
  23.                         position:"absolute",
  24.                         left:_pos.left,
  25.                         top:_pos.top,
  26.                         opacity:0
  27.                     });
  28.                 }
  29.                 //not ie6
  30.                 else {
  31.                     //hide
  32.                     if(options == "hide"){
  33.                         $this.hide();
  34.                         return;
  35.                     }
  36.                     //show
  37.                     $this.show();
  38.                 }
  39.                
  40.             });
  41.         }
  42.     });
  43. })(jQuery);

PS:flash遮挡DIV的问题并非此bug,可以通过设置flash的wmode属性(opaque或者tansparent),然后就可以通过z-index来控制覆盖关系了。

发表评论 »  ( 13 条评论 )

Flash Player 10升级导致SWFUpload程序异常

发表于: 2008年11月9日  所属分类: FLASH, JavaScript

关键字: , ,

  此前我分享了一些关于SWFUpload的东西,有一些朋友在网上跟我探讨他们在使用中遇到的问题,多数情况下都是他们对初始化时setting对象的属性没有了解清楚,配置错误甚至是遗漏造成了程序无法正常初始化。而前些天一个朋友在邮件里说他的SWFUpload程序在XP系统上运行正常,在win 2000系统下运行出现了问题。当时我第一反应是他的两个系统的浏览器环境不一致。可当我看了他发的Debug信息以后,我才发现问题和我想的不一样。

  在他的Debug信息中抛出了一个#2176的异常(Exception: Error: Error #2176),可是我查了一下我本地的AS帮助手册没有发现这个异常状态码。去Adobe官方DOC上一看,原来是一个运行时错误"Certain actions, such as those that display a pop-up window, may only be invoked upon user interaction, for example by a mouse click or button press."。

  继续查阅了下发现原来是FlashPlayer 10升级以后,安全策略更严格了,对于弹窗这类显示动作需要用户通过鼠标或者键盘交互来触发,无法像以前一样使用脚本直接触发了(类似HTML Form中的File表单,我们无法使用Javascript来触发文件选择对话框的弹出,一定需要用户点击"浏览"按钮)。我升级播放器以后测试了以前写的程序,果然出现了#2176错误。既然FlashPlayer 10有了这样的安全限制,那么SWFUpload目前版本岂不是不能使用了?

  我去SWFUpload官方看了下,果然十月份已经更新到了V2.2.0版本,同时加入了Google Code。我最近也忙了些,一直都没有再关注这个库。其实在官方论坛上已经有人提出了上述问题,而V2.2.0版本的Change Log也明确指出此版就是为了支持FlashPlayer 10而做的升级,同时也放弃了对FlashPlayer 8的支持。

  我又查看了下官方V2.2.0版修正的Demo,原来此版是在SWF中引入一个按钮,用户点击此按钮来触发文件选择对话框的显示,而此前版本中使用的selectFile()和selectFiles()由于无法兼容Flash Player 10,因此不能继续使用了。虽然功能是正常了,但我个人觉得仍然有个小小的不完美之处就是将一个Flash元素暴露在了用户面前(Flash元素上右键和HTML页面右键表现不一致),用户可能会有种"怪异"的感觉。

  V2.2.0的API文档也相应做了些修改,主要有以下五处更改:

  一、彻底放弃了对Flash Player 8的支持,只提供唯一版本的swf影片。

  二、由于现在的SWF需要显示在页面内,因此在setting中增加了一个必须的button_placeholder_id属性,该属性可以设置一个页面中的DOM元素ID,当SWFUpload初始化的时候,会用SWF影片替换此DOM节点。

  三、setting中增加了一系列关于按钮UI显示的属性,具体查阅我更新的SWFUpload v2.2.0 说明文档,也可直接查看官方的Demo。

  四、setting中增加了一个prevent_swf_caching属性,通过给swf后添加random参数来控制是否被浏览器缓存。官方的目的是为了解决基于IE引擎的浏览器的一个BUG。(PS:官方没有说明是什么BUG,不过在V2.0版本时,我在Maxthon中遇到了刷新BUG,当时我同样使用此方法更改了SWFUpload库,但BUG依然存在。)

  五、method中增加了一系列关于重置按钮UI的方法,具体查阅我更新的SWFUpload v2.2.0 说明文档

  PS:SWFUpload的此次升级主要是为了兼容Flash Player 10,增加了一系列的属性和方法来完成按钮UI的自定制,这样就使配置过程更加复杂了,或许可以把按钮的UI还是留给HTML中的DOM和CSS完成,而SWFUpload提供一个透明影片定位在页面中指定的按钮容器之上。我的这种设想是来自目前的WEB邮箱系统中很常见的自定义的附件上传按钮,实际上是使用CSS将File表单透明,然后定位到自定义的按钮之上,这样用户点击添加附件的时候,实际上点击的是File表单的"浏览"按钮,只不过它不可见罢了。(有时间我会专门针对这个实现分享点东西和大家一起探讨。)

  如果你还在使用SWFUploadV2.2.0之前的版本,那么赶紧使用V2.2.0版本修改你以前的程序,否则你的程序就存在不兼容问题,可能会造成用户无法正常使用。针对SWFUpload V2.2.0 API文档中的调整我也重新做了翻译,详细见SWFUpload v2.2.0 说明文档

发表评论 »  ( 17 条评论 )

写在国庆前夕

发表于: 2008年9月30日  所属分类: 生活随笔

关键字: , ,

一晃三个多月过去了,这片地儿都快长草了,惭愧。直到此刻,才能静静地坐在这里,梳理下这段充实而混乱的日子,无论如何,它注定是我人生中一段难忘的经历。在这里,我结识了很多互联网疯子。我们的口号就是,我们要的不仅仅是互联网人才,而是互联网疯子。

与工作

我和朋友戏称六月是我的闭关时间,去年六月迫不及待地从南京赶到北京,参与了公司新项目的封闭开发,那时团队的激情和热情都还历历在目,那人、那景,就如发生在昨天一般亲切。而今年六月,我又一次遇到了封闭,同样是匆匆忙忙地融入项目。从龙脉到西单,从孙武居到毛坯房,一群可爱的人都在为一个共同的目标而忙碌着(此刻,北京的同事还在忙碌着系统上线的调整,我向你们致敬,辛苦了!)。在新的Team带来惊喜和希望的同时,也带来了压力和挑战。累过、牢骚过,但更多的时候我感受到的是快乐和兴奋,因为我在和Team新的血液交融,因为我见证了“猫屁网”的一步步诞生。尽管它现在还是个婴儿,但我相信,它会迅速成长起来的。

与生活

绷紧的工作让我的生活彻底乱了,朋友聚会没了,户外运动没了,相机闲置了,单车也成了摆设……生活中的麻烦也让我彻底意识到,我的生活太缺乏计划性了。我觉得很多零碎事情不必去关注,这个很容易,那个无关紧要。但事实上呢?只能让自己越来越糟糕。前段时间房子问题弄得尴尬不堪,租了两处房子,自己还得继续找房子。回过头来想想,其实自己越是怕麻烦,最终反倒越是麻烦,生活上的抗风险能力得提高。这一点,以后得和小严沈楠同学学习。

与战友

曾经一起奋斗的哥们现在也都一一离去了,本来是约好六月骑行走川藏的,不过这下子估计遥遥无期了,第一我懒,第二70丁儿双双去了阿里,诶…要是换我这怕麻烦的人,我一想到那搬家,我就不考虑杭州了,不过西湖上骑骑车还是很有诱惑力的。涛、超和许大侠已经杀回长沙创业去了,起步总是艰难的,相信你们能抗过去,咋说也是五环飙车男啊,哈哈。我也很期待看到你们的东西快点上线。维波去了橙天,用郭儿的话说是去混娱乐圈了。很好,很强大,你的毅力是值得肯定的,每天从北五环到朝阳一个来回,那可不轻松。关于晓光,我挺惭愧的,让他一个人战斗了几个月,虽然这个项目只是个尝试,但也应该是认真对待,我的功课会随后补上。晓伟去了360,不过好像也没有大压力,每天群里的主角还是你啊。
在微视的这段日子里,大家相识就是缘分,能够相知那更是难得,大家都是如此真诚。我还记得刚到微视的时候晓光跟我说了一句话,做技术的人想法都很简单,不会耍什么手段。其实,这也是我所想要的团队氛围,简简单单。

与广州

去年十月份公司项目,我们到广州出差,那个时候也没有心情体会广州,潜意识下总觉得广州治安混乱,还是处处小心为妙。珠江、上下九都去逛了,但都逛得紧张兮兮的。今年因为猫屁网项目,再次来到广州,巧合的是,两次都是广州移动。顿时有了一种熟悉的感觉,不再那么拘束了,一个月下来,北京广州往返两次,我还是完好无损,看来治安也没有乱到令人恐怖的程度。其实用心感受下广州的绿,还是很不错的,至少我这次可以给我同事介绍,路两边的那种长胡子的树是榕树,小区里那种长得笔直的树是槟榔。对比下北京的生活,其实广州的生活节奏要慢很多,在这里生活也是个比错的选择。唯一难受的就是,这里气候我居然适应不了了,37度的天气,我居然上火加感冒...自己都彻底无语了。

与故人

意外得知一个八年没见的朋友也在广州,顿时很意外,居然能在广州相遇,一起吃饭、聊天,一下说了很多很多家乡话。那感觉,真爽,嗓子都快哑了,还是很爽。

八月份突然得知初中同学在北京的还有好几个,于是准备一起出来聚聚。还好从广州回来正好赶上了中秋,分别快八年的同学又都聚在一起聊天,那感觉太亲切了。还有,人大那草坪可以随便坐,太可惜了。

大学期间的一位教授来北京,联系了下北京的大学同学一起和老师聚聚,那么大年纪的老人,思维还相当清晰,顿时很佩服。学术方面侯老师是权威,可惜上学的时候我没有从事我专业方向,他们谈的学术问题太专业了,我听不懂,但听到熟悉的声音,看到熟悉的笑容,心里还是有说不出的满足。

一大学同学今年终于如愿考上了中山大学的研究生,正好今天去见了一面,聊了很多大学的事情,最终的结论,我们信息31一直都是一个创造神奇的班级,大家都是好样的。十年以后我们肯定能够再聚一次的。今天走在中大校园里的时候,那种感觉真好,也让我怀恋大学时光了。下周在南京的一帮同学准备聚会了,可惜我是赶不过去了,遗憾。

与家人

从上学的时候就一个人在外面,我最大的愧疚就是对父母,每年春节回家也待不了多久。自己有学习、有工作、有朋友,多数时候感觉不到孤单,但换位思考下,父母在家对孩子每日的担心和思恋是多么难熬啊。每次想到这里我都会觉得很愧疚,虽然每周都会准时给家里打电话聊上十几分钟,但我还是觉得有很深的愧疚。明天就从广州直接回家了,十一期间能陪陪父母,也算是一种奢侈了。

洗澡睡觉,明日起,远离电脑一星期 HOHO... 各位国庆节快乐

发表评论 »  ( 10 条评论 )

客户端上传工具-SWFUpload

发表于: 2008年6月16日  所属分类: FLASH, JavaScript

关键字: , ,

年初在改进公司的视频文件上传体验时接触到了SWFpload,当时的版本还没有Release,功能和文档都还在完善中,遇到了IE下的刷新BUG,可把我折腾了一番。由于手头事情太杂了,当初许诺下的“等我项目结束时希望SWFUpload放出正式版和官方确定的接口文档了,到时再针对传统文件上传的各种方式和SWFUpload功能包唠叨几句”的话,我也一直都没有实现,很是惭愧。

最近由于项目中多文件上传的需求,我才发现SWFUpload已经升级到V2.1.0版了,功能和文档都已经能够满足复杂的项目需求了,因此特把我之前的许诺补上,并附上针对V2.1.0版的SWFUpload翻译。(此版本也已经修正了IE的刷新BUG,不再需要使用我之前的解决方式了。)

一、首先来比较下目前的几种的客户端上传:

1、File表单

使用标准的HTML元素提供的File表单是最原始、传统的上传方式,他的优势在于浏览器的广泛兼容性,除了服务端需要处理Files信息以外,不需要额外的处理程序即可完成文件上传。

但使用File表单上传文件会造成页面的刷新,尤其是在上传大文件的时候,在文件上传过程中,用户需要傻等在一个空白页面前,没有任何反馈信息来提示用户当前的上传进度。同时无法在客户端对文件大小做检测。

2、IFrame结合File表单

使用一个含有file表单的iframe来完成文件上传,能够避免文件上传过程中的页面刷新,在一定程度上改进了用户体验,但同样没有解决大文件上传时候缺少反馈信息的问题。相比File表单上传,此方式还需要对程序做额外的处理,同时需要JS的支持,复杂度稍微增加了一些。

3、IFrame、File表单结合AJAX

在方式2的基础上引入AJAX来实时跟服务端脚本获取当前的上传进度,实现了页面无刷新、实时更新上传进度的功能。但程序的复杂度又增加了一个级别,由于要不断跟服务端发送请求,同时也增加了服务端的压力。

4、Activex控件

使用控件方式完成的上传在功能和效率上都很不错,页面无刷新、显示上传进度、批量上传,个人认为遗憾就在于需要在浏览器上安装控件,而且只能支持IE,弹出那么个安装提示可能会吓倒多数用户,开发的复杂度也提高了。

 5、Flash

Flash的FileReference类提供了文件上传功能,相对于传统的File表单而言,Flash上传能够获取客户端的文件的更多信息反馈,例如文件大小、类型、创建、修改时间等,利用这些信息可以在客户端对文件进行类型和大小等属性的一次过滤。

FileReference类提供了多文件上传功能。

Flash直接向服务端发送文件数据,因此Flash本身是可以随时知道文件上传数据而显示上传进度,而不需要使用AJAX的方式不断跟服务端发送请求增加服务端的压力。

 弊端在于客户端需要Flash播放器的支持,而且在一个页面中插入一个Flash,从UI元素的统一角度来看,似乎有些别扭,如果页面需要更改风格,那么Flash还需要重新修改然后编译,而且程序开发的复杂度也提高了。

6、Flash结合JavaScript

在方式5的基础上,将Flash隐藏起来,利用JavaScript来控制Flash元素处理文件上传,Flash使用ExternalInterface来完成跟JavaScript的通信,将页面元素的控制权交给JS。这样就避免了方式5中的UI元素不统一、修改不灵活的弊端。但代价就是Flash程序开发的复杂度再次提高了,同时也需要更高的JS和XHTML开发能力。

以上列举了目前我所了解的浏览器环境下文件上传的方式,并对其优劣都做了简单的罗列,在实际开发中我们可以根据自己的应用来选择合适的方式,假如我们的需求只是用户给自己上传一个10K不到的头像,如果我们还大费周折地实现了头像上传的进度提示,那就是事倍功半了,因为在目前的绝大多数网络情况下,一个10K的文件传输是一眨眼的功夫。



阅读这篇文章的其余部分 »

发表评论 »  ( 7 条评论 )

推荐【一对一孤儿资助项目】

发表于: 2008年5月18日  所属分类: 生活随笔

关键字: , ,

那场灾难已经过去5天了,我相信每一个中国人都是无比悲痛的。

前天晚上丁儿跟我说打算去四川做志愿者,当时我确实是惊了一下,最初认为是他一时激动了,毕竟现在都是有工作在身的人了,而且也没有相关的救护知识,怎么能去做志愿者呢?

后来公司知道这一情况以后也了解了下目前志愿者的需求情况,目前确实有很多外围工作需要志愿者去做,对于丁儿的这个想法也给予了很大的支持,看到所有同事在写上祝福的国旗上签上自己的名字,看到大家给灾区募捐爱心买药,我心里也有种暖暖的感觉了,原来爱心是可以蔓延的

明天哥们就要动身了,在这里再次祝福你一路顺风,平安去,平安回,你是好样的!!

之前一起骑行的一个朋友已经踏上去四川做志愿者的征途了。

昨晚得知70也在行动了,他在网上联系了一个灾区心理咨询的老师,给他们做网络的技术支持了。

一直我都在思考,除了捐款我们还能做点什么,突然想起我的一位被好心人一对一资助的同学,我就知道自己能做什么了。目前对我而言,收养孤儿不现实,但一对一的资助一到两名灾区儿童应该是力所能及的,我相信也是我们周围很多人都能够做的事情。

在网上查了下相关的实施办法,发现很多想资助孤儿的人也都在找相关信息,因此把目前我找到的还比较可靠的消息发布出来供大家参考:

资助一名孤儿的标准(一对一结对资助,捐赠人和受助人互动,保证信息公开透明)

  科 目 费用标准(每人)

  一年的生活费用(100元/月) 1200元

  一年关爱活动费 150元

  孤儿寻找、核实、探访、管理 150元

  合 计 1500元

你还可以在这里填写一个资助申请(PS:页面的右下角,不是很明显)
更多资助方式见这里这里,希望你也能够加入到这个行列中来,比起灾区的人民,我们此刻真的是幸福太多了。人生的快乐不在于索取,而是付出

发表评论 » 

ActionScript3初体验

发表于: 2008年5月7日  所属分类: FLASH

关键字: , ,

  当我意识到AS3是革命性的时候,我对Flash的热情一下又被点燃了,立马以公司项目中的FLV播放器入手开始了AS3的体验实战之路。这半个月来多亏同事的支持,项目中他们分担了很多工作,让我能够有更多时间来潜心重写FLV播放器,今天终于发布了一个具备基本功能的Demo,实现了基本的视频控制、自适应容器尺寸、全屏播放,但真正要使用到项目中来,还有一些细节工作需要去做,例如外部数据接口的预定义,对广告和RSS的支持。

  此版播放器的重写最重要的目标是要将UI和程序完全分离开,以满足项目中播放器样式频繁更改的需求。在开发过程中,我也更深刻体会到了AS3在OOP上的巨大变革,相对于AS2而言,新的体系更加严谨,起初我也有点不习惯,例如以前常用的类和对象都不见了;现在的显示对象复杂的继承关系似乎难以记忆了;严格的编译检测让自己很受挫;新加入的运行时检测也让人很恼火等等。但当我遇到越来越多问题,解决越来越多问题的时候,我对AS3的整个体系的认识也更清晰了,AS3还是很值得称赞的,随后我会发布一些自己遇到和解决的问题的心得(PS:我把本地的WIKI也同步到网上一份了,这里有一些零散的笔记,可能对你有一些帮助)。

发表评论 »  ( 3 条评论 )

ActionScript3.0是革命性的

发表于: 2008年4月13日  所属分类: FLASH

关键字: ,

  上个周末去书店时碰巧看到了AS3 CookeBook,我记得在apollo的alpha版快出来的时候,7yue就推荐过这个小册子,只不过我已经习惯了AS1和AS2,对于一个新技术的学习还是持保守态度,加上这一年以来项目需求中更多的是DHTML+AJAX的工作,也无暇去了解AS3,一直都以为它只是对AS2的一个扩充,是Adobe换汤不换药的商业行为。可当我翻看了下CookeBook的目录,然后又针对性地看了几节以后,心里顿时有了一种很激动、兴奋的感觉,AS3并不是对AS2的补充,而是颠覆性的,它对Flash的发展是革命性的。

  上周开始抽空研究AS3,目前我还一直都处于兴奋状态,恨不得能够不睡觉地把Help文档通读一遍,就我目前的认识对AS3的重大转变先写个引子,希望对AS2开发者给个友好提示,如果你不抵触学习新技术,那么还是尽快转到AS3来吧(PS:目前接触时间有限,文中有理解不当或者错误之处望谅解、指出,随后的学习中会我也会继续发布一些体会)。

  一、全新的“显示对象”架构
  FlashPlayer9中加入了一套新的AS虚拟机器(AVM2),它提供了一套新的显示API,相对于之前的版本执行和渲染效率提高了不少。在AS3以前FLASH中的可编程的显示对象只有MovieClip和TextField,架构很简洁,他们都是直接从Object类继承的。在AS2的面向对象体系引入以后,一个MC类的属性和方法加起来近百个,目的就是为了让AS对MC的控制能够“随叫随到”,但是以牺牲效率为代价的。例如我们动态复制了几个MC到特定的坐标,而没有任何交互需求,但这些新的MC实例却依然具有了很多我们并不需要的属性和方法,因此很多编程人员都会抱怨MC是一个笨重的类。
  
  FP9中新的显示架构彻底颠覆了“MovieClip是灵魂”的设计(AS2那套东西已不再沿用了),这个重大的更新主要体现在对显示对象的抽象更细致、清晰了。简单说来从概念上划分为了显示对象、容器对象、可交互对象,在这个基础上提供了更便捷地遍历显示列表的方法,添加、删除可视元素的方法、自动化地深度管理等。
  FP9的显示层次结构

  从功能上详细提供了15个可视对象类,这就让我们能够根据实际需要选择合适的对象来实例化,而避免无用消耗。对这些显示对象的具体特性可查阅帮助文档,这是AS3显示编程的灵魂。
AS3中的核心可视类
  
  二、清晰的事件机制
  从AS2中就引入了事件侦听模型,但由于AS1和AS2编程的随意性以及AS开发人员更多的是设计转行的,很多人还是习惯使用_mc.onRelese = function(){},甚至是on(release){},这些不同实现的优劣这里就不再重复讨论了,很多文档都有详细地对比说明。正是因为事件侦听模型的巨大优势,所以在AS3中有且只有只一种事件模型,它是支持了W3C DOM3事件规范的标准,对于它提供的各种广播事件也需要熟记于心。
  在新的事件模型中,this对象能够自动找到它的原始对象实例,而不用再使用Delegate这种和怪异地方式来指定事件处理函数的上下文引用了。
  更多细节需要参阅文档,熟悉这个新的事件模型是很有必要的,对于交互编程而言,这个是重点之一。

  AS2是不支持事件流的,现在你不用再为此头疼了,因为支持事件流是AS3的事件机制的又一重大更新,对于事件流的捕获、目标、冒泡这三个过程你需要很清楚,每当你初始化一个交互元素时,你就需要在脑海中迅速地按顺序触发这些过程,这是交互编程的重点之二。

  三、更为便捷的库元件绑定和文档类绑定
  在AS2中我们如果需要重新初始化一个目标MC的实例,通常会采用duplicateMovieClip或者attachMovie来实现,但这两个实现都存在弊端和不便,局限性比较大。AS3提供了一种更便捷的方式来实例化一个目标元素的实例。在AS2的组件开发中我们通常都会使用库元件的类绑定,但在UI和程序协同、构造函数传参方面还是不太方便。而AS3中我们完全可以用AS自由控制库元素实例化到舞台上,例如:

//在库中将目标MC的导出类设置为FileUpLoad
//如果只是想显示库中元素,那么你没有必要额外建立FileUpload文件,编译器会帮你自动搞定
//在AS中实例化一个图片上传UI
var picUpload_mc = new FileUpload();
//添加到舞台上显示
stage.addChild(picUpload_mc);

  对于库绑定的细节需要详细了解,其中还涉及到一些实际问题的实现方式,例如如何在类中访问绑定库元件中的元素等。但我个人认为利用AS3提供的这一新功能,能够更好得设计程序的架构,更符合MVC的开发原则,具体实现还需要在以后的研究中来探索,也希望和大家一起交流。

  如果你接触过Flex开发,那么文档类的绑定就很熟悉了,这是FLASH开发环境所不提供的,但在FLASH CS3中提供了这一功能,目的还是规范开发。

  四、丰富的功能包支持
  就FLASH CS3开发而言,Adobe沿用了Flash之前版本的一些类库,主要都在fl.*包中,在这个基础上有更新了一些顶级包,同时又提供了一些新的包,主要都在adobe.utils中。除此以外,你还可以使用Flex作为开发平台,Flex提供了更为丰富的功能包和组件。

  五、语法特性
  AS3语法特性上也有一些变化变化,目前我针对下面几个做过测试:
  1、在Number类型的基础上,新增了int和uint类型。
  2、类型检测方面增加了is和as两个运算符,AS3提供了运行时的类型检测,在这之前只是提供编译检测。
  3、各种数据类型的值在undefined时,现在都会给一个特定的默认值(编程中需要格外小心)。 
  4、对于函数的执行,需要严格匹配参数个数,并提供了一种...(rest) 形式的参数来支持任意多参数的调用。
  5、面向对象体系更细致了,增加了包的概念,增加了inernal和final的两个修饰符,对于类中public、private、proteced的访问权限也都有变化,对于重写超类的方法需要利用override关键字做申明。  

  六、其他特性
  上面的五点是我目前接触到的,同时也是个人认为最重要、最有进步的变革,除此之外还有一些重要的变化特性,例如在二进制、socket通信、E4X、正则表达式、文本显示、全屏模式等方面也都有一定的改进,有待于在实际操作中来熟悉。

  PS:虽然近一年没有怎么系统地做Flash的东西了,但从WEB前端的发展动态来看,Flash的交互性越来越被重视了,就目前应用而言,除了在WEB上的RIA以外,在PC桌面应用上,依托于apllo或者yahoo Widget这样的运行时环境,Flash的应用应该会更有前景,界面丰富、交互灵活、相对较低的开发门槛,这些都是他的优势所在。(手机开发没有接触,这个平台对FlashPlayer的支持版本不太清楚,但我相信只要有利益存在,技术自然会被商业驱动起来的。)

发表评论 »  ( 3 条评论 )

年轻的我们都需要沉淀

发表于: 2008年3月25日  所属分类: 生活随笔

关键字: ,

  人是如此容易受环境的影响,在遇到一些人、发生一些事以后,心态就逐渐发生变化了,曾经认为自己的心态已经够平和了,但经历了这个“混乱”的时期后发现自己的平和还不够彻底。因为年轻而过于理想,因为年轻而过于浮躁。

  在经历了这样一段混乱的时期之后,很感谢那位跟我聊了很多切身感受的同事,那次的聊天让我清醒了很多,原来自己在不知不觉中已经忘记了当初选择这个Team的原因,忘记了自己坚持的东西。幸好现在又清醒了,再回过头思考下这个经历,也体会到了一点点社会的复杂,年轻的我们需要经验和心态的沉淀。

  看着一起奋斗过的同事一个个离去,心里确实很难受。上次有这种感觉还是在我实习离开1906的时候,虽然隽辰说公司的人员流动是很正常的,但从我个人而言,情感上始终过意不去,觉得自己有负于团队,有负于大家对我的关照。但我现在能够很理性地看待同事的离职了。每个人的都有自己的选择,因为生活压力,抑或是因为自己的梦想,甚至是因为自己的浮躁。如果无法认可这个团队,那么最好的选择就是大家好聚好散。既然大家都选择了创业团队,那么就需要有创业的勇气和激情,就需要考虑到了创业的艰辛和风险,而不是遇到了困难就犹豫了。恰好,年轻的我们总是会不自觉地理想地看待问题,很小的麻烦可能会被我们放大,然后愈演愈烈,最终影响到了团队的士气,让大家都很沮丧。

  大浪淘沙,年轻的我们需要懂得坚持,因为我们太需要沉淀了,只要我们用心、务实地做好自己的事情,坚持下来,那就没有绝对的失败。上帝在关闭一扇门的时候,定会为我们打开另一扇门。

发表评论 »  ( 11 条评论 )
下一页»

关于我

卢 力,LuLi

北漂路上..

ID:小力,vsky


热爱互联网,关注Web前端技术,正努力追寻中。乐于交友,愿与你分享探讨技术点滴。
  热爱生活,向往简单、自由的生活方式,故取名 SimpleLife...

联系方式:
QQ:3292497
Gtalk:yoyokings@gmail.com

内容搜索

聚合及订阅

    feedsky
    抓虾
    google reader
    my yahoo
    netvibes
    鲜果

文章分类

最新笔墨

最新评论

我的圈子

如需修改,请与我联系
注意:排序不分先后顺序: