kenlistian

勤学多思

  IT博客 :: 首页 :: 新随笔 ::  :: 聚合  :: 管理 ::
  412 随笔 :: 0 文章 :: 23 评论 :: 0 Trackbacks

#

ruby的启动

ruby 【option】 【--】【programfile】 【参数】

其中option包括以下,目前还是不是非常清楚,但是明白可以通过ruby

调用脚本方式是知道的。

 

-0数字
    以8进制数指定输入记录分隔符('$')
    若不指定数字的话,分隔符是空字符(等同于$/="\0")。数字后面可以有其他的开关(switch)。 
    -00代表段落模式(等同于$/=""),-0777(因为这个代码不代表任何文字)表示将文件的全部内
   容一次性读入(相当于$/=nil)。
-a

与'-n'或'-p'一起使用时,可以打开自动拆分模式(auto split mode)。自动拆分模式将在各个循环前执行以下动作。
  $F = $_.split
  若没有同时指定'-n'或'-p'选项的话将不起作用。

-C directory
    执行脚本之前,先移动到指定目录。
-c
    只对脚本进行编译,而并不执行。编译后若没发现语法错误,则显示“Syntax OK”。
--copyright
  显示版权信息。
-Kc
    指定Ruby要处理的汉字编码。若是'E'或'e',则Ruby认定字符串或访问文件中的汉字编码为EUC。同样,若是'S'或's'的话则认定为SJIS。若是'U'或'u'则当作UTF-8处理。'N'表示不对汉字进行处理。该选项的默认值就是N(NONE)。
 -d
--debug
   以调试模式执行脚本。将$DEBUG设置成true。在脚本中可以使用该变量反应调试状态
 
-e script   没搞懂。。。
    在命令行中指定脚本。添加-e选项后,就不会从参数中抽取脚本文件名了。
  若多次使用-e选项时,系统会按照以下方式处理。
下列各表达式的意义相同。
ruby -e "5.times do |i|" -e "puts i" -e "end"

ruby -e "5.times do |i|
  puts i
end"

ruby -e "5.times do |i|; puts i; end"
-Fregexp

regexp指定给输入域分隔符(field separator)。

-h
--help

显示命令行选项的简介。

-i[extension]    替换操作,好像用的不多

对参数中指定的文件内容进行替换(in-place edit)。原始文件将被加上扩展名并保存下来。
   若没有扩展名的话,将不会进行备份,而且只有替换后的文件会被保留下来。

-I directory

指定(追加)加载文件的路径。指定的目录将被追加到Ruby的数组变量($:)中。

-l

进行行尾自动处理。首先,将$\改为$/的值,在print输出时添加换行。若使用了-n标志或-p标志的话,将对gets读入的各行末尾进行String#chop!处理。

-n

若使用了该标志,则整个程序会像sed -n或awk一样,被

while gets
 ...
end

括起来运行。

-p  与-n标志相仿,在各循环后输出变量$_的值。

例:

% echo matz | ruby -p -e '$_.tr! "a-z", "A-Z"'
MATZ
-r feature

执行脚本前,先对feature指定的库执行require操作。与'-n'选项、'-p'选项一起使用时特别奏效。

-s

对跟在脚本名后并且以'-'开头的参数进行解释,并将其值赋值给同名的全局变量。遇到以'--'开头的参数就停止解释,并将该参数从ARGV中删除。

例:

#! /usr/local/bin/ruby -s
# prints "true" if invoked with `-xyz' switch.
print "true\n" if $xyz
-S

该选项表明,当脚本名不是以'/'开头的时候,要使用环境变量PATH的值搜索脚本。若您的机器不支持#!的话,可以使用下列方法模拟#!的运行:

#!/bin/sh
exec ruby -S -x $0 "$@"
#! ruby

因为第1行的关系,系统把脚本交给/bin/sh。/bin/sh执行第2行后启动Ruby解释器。在-x选项的作用下,Ruby解释器把从'#!'到包含'ruby'的行的内容全部读入。

根据系统的不同,$0未必包含完整路径,因此有必要使用'-S'选项来告诉Ruby在必要时搜索脚本。

-T[level]

执行不纯度测试。若给level指定了一个值之后,安全等级也会使用这个值。省略level时,其值为1。对于CGI程序来说,将其指定为-T1比较合适。$SAFE的等级也将被设定。

-v
--verbose

冗长模式。启动时显示版本信息,然后将内部变量$VERBOSE设为true。当此变量为true时,众多的方法在运行时会显示冗长的信息。若只设定'-v'选项,而没有其他参数时,启动后会先显示版本信息,然后就结束运行(不会等待来自标准输入的脚本)。

--version

显示Ruby的版本信息。

-w

不显示版本信息的冗长模式。

-W[level]

ruby 1.8 特性

可以指定3种级别的冗长模式,如下所示。

  • -W0: 不显示警告
  • -W1: 只显示重要警告(默认)
  • -W2 or -W: 显示所有警告

内部变量$VERBOSE被分别设置为nil,false,true。

-x[directory]

从message中取出脚本并执行。读入脚本的范围是从'#!'开始,直到包含'ruby'的行为止。用EOF(文件结束),^D(controlD),^Z(controlZ)或保留字_END_来指定脚本结束。

若指定了目录名的话,则在执行脚本前移动到该指定目录。

-y
--yydebug

编译器调试模式。编译脚本时显示语法分析的过程。该显示过程会很漫长,可能只对那些想调试编译器的人有用。

posted @ 2006-12-28 12:11 kenlistian 阅读(216) | 评论 (0)编辑 收藏

Ajax

“Asynchronous JavaScript and XML”(异步JavaScript和XML),是一种创建交互式网页应用的网页开发技术。它使用:

* 使用XHTML+CSS来表示信息;
* 使用JavaScript操作DOM Document Object Model进行动态显示及交互;
* 使用 XML 和 XSLT 进行数据交换及相关操作;
* 使用 XMLHttpRequest对象与Web服务器进行异步数据交换;
* 使用 JavaScript 将所有的东西绑定在一起。

 

类似于DHTML或LAMP,AJAX不是指一种单一的技术,而是有机地利用了一系列相关的技术。事实上,一些基于AJAX的“派生/合成”式(derivative/composite)的技术正在出现,如“AFLAX”。

 

开发Ajax应用面临的挑战及解决方案,

一句话:目前的ajax并不能取代soap方式的客户端和webserver处理模式。

对程序员而言,开发Ajax应用最头痛的问题莫过于以下几点:

1. Ajax在本质上是一个浏览器端的技术,首先面临无可避免的第一个问题即是浏览器的兼容性问题。各家浏览器对于JavaScript/DOM/CSS的支援总有部分不太相同或是有Bug,甚至同一浏览器的各个版本间对于JavaScript/DOM/CSS的支援也有可能部分不一样。这导致程序员在写 Ajax应用时花大部分的时间在调试浏览器的兼容性而非在应用程序本身。因此,目前大部分的Ajax程序库或开发框架大多以js程序库的形式存在,以定义更高阶的JavaScript API 、JavaScript对象(模板)、或者JavaScript Widgets来解决此问题。如prototype.js。

2. Ajax技术之主要目的在于局部交换客户端及服务器间之数据。如同传统之主从架构,无可避免的会有部分的业务逻辑会实现在客户端,或部分在客户端部分在服务器。由于业务逻辑可能分散在客户端及服务器,且以不同之程序语言实现,这导致Ajax应用程序极难维护。如有使用者接口或业务逻辑之更动需求,再加上前一个JavaScript/DOM/CSS之兼容性问题,Ajax应用往往变成程序员的梦靥。针对业务逻辑分散的问题,Ajax开发框架大致可分为两类:
* 将业务逻辑及表现层放在浏览器,数据层放在服务器:因为所有的程序以JavaScript执行在客户端,只有需要数据时才向服务器要求服务,此法又称为胖客户端(fat client)架构。
   服务器在此架构下通常仅用于提供及储存数据。此法的好处在于程序员可以充分利用JavaScript搭配业务逻辑来做出特殊的使用者接口,以符合终端使用者的要求。但是问题也不少,
  主因在第一,JavaScript语言本身之能力可能不足以处理复杂的业务逻辑。
   第二, JavaScript的执行效能一向不好。
   第三,JavaScript存取服务器数据,仍需适当的服务器端程序之配合。
   第四,浏览器兼容性的问题又出现。有些Ajax开发框架如DWR企图以自动生成JavaScript之方式来避免兼容的问题,并开立通道使得JavaScript可以直接叫用服务器端的 Java程序来简化数据的存取。但是前述第一及第二两个问题仍然存在,程序员必须费相当的力气才能达到应用程序之规格要求,或可能根本无法达到要求。

* 将表现层、业务逻辑、及数据层放在服务器,浏览器仅有使用者接口引擎(User Interface engine);此法又称为瘦客户端(thin client)架构,或中心服务器(server-centric)架构。浏览器的使用者接口引擎仅用于反映服务器的表现层以及传达使用者的输入回到服务器的表现层。由浏览器所触发之事件亦送回服务器处理,根据业务逻辑来更新表现层,然后反映回浏览器。因为所有应用程序完全在服务器执行,数据及表现层皆可直接存取,程序员只需使用服务器端相对较成熟之程序语言(如Java语言)即可,不需再学习JavaScript/DOM/CSS,在开发应用程序时相对容易。缺点在于使用者接口引擎以及表现层通常以标准组件的形式存在,如需要特殊组件(使用者接口)时,往往须待原框架之开发者提供,缓不济急。如开源码 Ajax开发框架ZK目前支援XUL及XHTML组件,尚无XAML之支援。

3. Ajax是以异步的方式向服务器提交需求。对服务器而言,其与传统的提交表单需求并无不同,而且由于是以异步之方式提交,如果同时有多个Ajax 需求及表单提交需求,将无法保证哪一个需求先获得服务器的回应。这会造成应用程序典型的多程序(process)或多线程(thread)的竞争(racing)问题。程序员因此必须自行处理或在JavaScript里面动手脚以避免这类竞争问题的发生(如Ajax需求未回应之前,先 disable提交按钮),这又不必要的增加了程序员的负担。目前已知有自动处理此问题之开发框架似乎只有ZK。

 

 

posted @ 2006-12-22 11:07 kenlistian 阅读(145) | 评论 (0)编辑 收藏

仅列出标题
共42页: First 34 35 36 37 38 39 40 41 42