JavaScript Eclipse 插件助您一臂之力,提高 JavaScript 生產力指日可待
JavaScript Development Toolkit(JSDT)是一種開放源碼插件,它將健壯的 JavaScript 編程工具引入到 Eclipse 平臺中。JSDT 使開發更加流暢、簡化了編碼并提高了純 JavaScript 源文件和 HTML 內置的 JavaScript 的生產力。
JavaScript 開發并不容易。瀏覽器兼容性參差不齊、文檔非常糟糕、工具貧乏,這些因素使問題進一步惡化。幸運的是,隨著最近針對 Eclipse 的插件集 JavaScript Development Toolkit(JSDT)的發布,工具匱乏的局面有望得到改善。
Eclipse 是一個開源的 IDE 框架,具有提高擴展性和靈活性的架構。JSDT 作為插件在 Eclipse 中運行。在 Eclipse 中,JavaScript 并不是什么新鮮的概念,因為已經可以從其他插件獲得 HTML 和一些 JavaScript 支持,但是 JSDT 的獨特之處在于其所提供的工具的健壯性和復雜性,這可顯著提高 Web 開發的生產力。
JSDT 提供的許多特性和核心設計都可以在 Java Development Toolkit(JDT)中找到。JSDT 將要代替 Web Tools Platform V3.0 發行版中當前的 JavaScript 編輯器。
您可能想知道為什么 JavaScript IDE 會如此流行。隨著 Web 2.0 的流行以及大量開發人員都熱衷于在博客和社區頁面中使用 JavaScript,大量新的 JavaScript 工具不斷出現。盡管如此,Notepad 和瀏覽器的 Refresh 按鈕仍然是大多數程序員首選的 JavaScript 開發環境。
問題在于 JavaScript 語言的解釋性。與 Java™ 或 C 語言不同,JavaScript 是一種松類型的語言,并且很難實現精確建模。對于較為正式的語言,需要優先考慮已編譯代碼的效率,并且對語言的靈活性有所限制。JavaScript 的目標則不一樣。各種因素試圖分化趨向同一個平臺的開發人員,這導致了語言的不一致性。從工具和開發的角度來看,這些不一致性使問題更加復雜。
瀏覽器并不是惟一的問題。面向對象的 JavaScript 是一種補充而不是關注的焦點。Ajax 工具箱努力使 JavaScript 朝面向對象方面轉變 — 但是各自采取不同的方式。這可能會使標識對象和類結構變得很困難。這種語言有幾個嚴重的漏洞,程序員利用它們實現一些使用其他方式難以實現的技巧,這使問題更加嚴重(或者更好,取決于您詢問的對象)。其中一個例子是將主要的代碼塊封裝到一個 evalf(..)
函數中,使它只在運行時有效。我們目前仍然在克服這個問題,以便在 JSDT 中精確建模。
目前可以使用一些并不完整的 JavaScript 工具。但是很多流行的工具還不能提供真正的上下文感知內容幫助,因為它們缺少真正的 JavaScript 語言建模機制。在模型較少的 IDE 中,通過使用靜態平面文件列出可用的類型,可以實現內容完成和工具功能。這些類型根據輸入的部分字符動態調整,并且通常不會選擇代碼中定義的對象成員。內容完成對上下文不敏感,因為如果沒有模型的話,可實現的功能將受到很大限制。
如果沒有語言模型,則很難或者不可能將代碼放入到上下文中。由于很多編程元素都依賴于代碼的上下文,因此使用工具建立上下文十分重要。缺少模型和代碼上下文的 IDE 同樣也會缺少充分的類型解析和驗證、作用域、可視性,或者其他任何對簡化開發非常重要的良好驗證功能。
![]() ![]() |
JSDT 對 JavaScript 語言建模并實時隱含類結構,這通過一種全新的方式來實現。首先,構建基本的語言元素。其次,推理引擎或引擎幫助填補所有類結構和語言差異。
可以將推理和建模流程看作一個操作棧。模型的開始部分是 JavaScript 源代碼。通過使用類似 Eclipse JDT 的引擎,將源代碼轉換為私有的語言模型。語言的純模型遵守 ECMA-3 標準。
對 JavaScript 語言建模后,下一步是管理類型和類推理。許多基于 JavaScript 的工具箱(例如 Dojo、Rico、Prototype)通過自己的技術使 JavaScript 面向對象編程更加方便。JSDT 使用定制的、工具箱感知的推理引擎在工具箱內部識別類和類型結構。這些類和類型隨后可以添加到語言模型中。
最后,將私有模型及其推理部分轉換為公共語言模型。公共語言模型可用于源代碼、重構和 as-you-type 工具。如果其中一種工具需要修改一些 JavaScript 源代碼,就得先在公共模型中進行修改,并最終轉換到 JavaScript 源代碼。
即使語言模型為描述 JavaScript 源代碼和上下文提供了基礎,還需要另外一個重要因素:環境上下文。JSDT 必須在運行 JavaScript 的全局作用域時建立可用的變量和類型。這些變量和類型根據 JavaScript 的運行時環境而有所不同。當 JavaScript 在 Web 瀏覽器上下文中運行時,對象、類型、表示屏幕數據的字段以及瀏覽器對象在全局作用域中都是可用的。如果代碼是針對其他內容而不是瀏覽器,那么整個對象集可能會不同。
JSDT 使用庫機制管理項目中的通用對象、變量和類型。可以將庫添加到項目中,以提供特定于用戶目標運行時環境的對象和變量集。如果存在兩個定義沖突成員的庫,則在相應的用戶接口中聚合并注釋這些成員。這有助于創建在瀏覽器或環境之間通用的方法。
為流行的瀏覽器預打包庫非常簡單。庫被捆綁在一個插件中,該插件包含有定義對象和類型的 JavaScript 源文件。當 JSDT 對源代碼編輯器中打開的文件進行建模時,它首先對文件的源代碼建模,然后將項目的庫集合中的所有源文件添加到模型。庫源文件永遠不會進行驗證,只用于定義對象結構、附加在懸浮式幫助和內容完成中可見的 JsDoc。
雖然庫的主要功能是管理 JavaScript 的運行時上下文,但是它還提供了另一個重要特性 — 處理源文件交叉引用。純 JavaScript 不具備顯式的 include 函數。開發人員的一個不良習慣就是將函數散布到多個源文件中。庫配置頁面可以幫助管理源文件之間的交叉項目可見性。如果某個項目文件夾被標記為一個源文件,那么該文件夾中的所有 JavaScript 將包括在全局作用域中。使用 exclude 模式可以限制文件夾。
![]() ![]() |
![]() |
撇開較高層的設計不談,我們仔細看看這些特性。JSDT 的一些可視性較弱但非常重要的特性包括:相同文字突出顯示、自動閉合大括號(以及圓括號、引號)以及自動縮進等。因此可以說,“只要是良好 IDE 應該具備的,JSDT 都提供支持”。
內容完成可以通過 Ctrl+Space 鍵任意調用。圖 3 展示了內容幫助調用文檔對象。內容完成對上下文敏感,并且基于全局作用域和 JavaScript 模型。完成條目顯示字段名、字段類型和字段的聲明類型。
如果 IDE 可以主動確定代碼錯誤,它將非常有用。JSDT 可以檢測三種主要錯誤類型:語法/語言錯誤、類型/字段/方法可視性、流或邏輯錯誤。所有的錯誤警告級別都可以通過首選項頁面進行單獨配置。
JSDT 試圖解析對象的所有字段和方法。未解析的方法則標記為錯誤。
JSDT 還可以查找并標記語法錯誤。下面的 for()
語句丟失了一個分號。
圖 6 演示了流分析。由于 return
語句后面的所有代碼都不能執行,因此將其標記為錯誤。
一些錯誤具有快速修復選項。在圖 7 中,當用戶單擊未解析變量 formyValue
旁邊的錯誤標記時,JSDT 將顯示一些糾正錯誤的選項。
源代碼有時會混亂。您可能期望易于閱讀、結構良好、格式化良好的代碼。這就需要在進行開發和調試時對代碼進行格式化。JSDT 支持許多 as-you-type 格式化特性,比如可配置自動縮進和字符成對匹配。這些特性都有助于加快開發和提高可讀性。
如果您收到的代碼非常混亂,該怎么辦?只需要單擊一下鼠標,JSDT 代碼格式化程序就可以整理并重新格式化混亂的 JavaScript 代碼。格式化引擎是高度可配置的,因此可以導出配置供團隊共享。
上面列出的僅是 JSDT 支持的特性的一部分。下面列出非常簡單但必須具備的 JSDT 特性:
![]() ![]() |
![]() |
如果需要一種免費的 Web 開發環境,請選擇 Eclipse。由于新增了 JSDT,Eclipse 的 JavaScript 能力超越了市場上其他同類產品。開放源碼項目促成了 JSDT 的快速發展,JSDT 將像 JavaScript 一樣快速地演進。
![]() |
||
|
![]() |
Bradley Childs 2004 年畢業于 Texas A&M University。他在 IBM 從事中間件開發,后來又轉到新興技術方面。他和 Phil Berkland 密切合作開發 JSDT。他在 Ajax Tooling Framework 項目社區中非常活躍。 |
下面是最新一期的Web服務器排名,其中Nginx已經上升到了第四位,太牛X了
Vendor | Product | Web Sites |
---|---|---|
Apache | Apache | 84,309,103 |
Microsoft | IIS | 60,987,087 |
GFE | 10,465,178 | |
Unknown | Unknown | 4,903,174 |
nginx | nginx | 2,125,160 |
Oversee | Oversee | 1,953,848 |
lighttpd | lighttpd | 1,532,952 |
Other | Other | 1,150,202 |
GNR | GNR | 425,029 |
Zeus | Zeus | 405,724 |
IdeaWebServer | IdeaWebServer | 382,524 |
Sun | Sun-ONE-Web-Server | 349,704 |
Apache | Coyote | 338,376 |
Resin | Resin | 321,746 |
Jetty | Jetty | 259,558 |
下載地址:http://www.myeclipseide.com/module-htmlpages-display-pid-4.html
另外還有
Blue Edition: ALM & Open Source for WebSphere
MyEclipse is proud to announce availability of MyEclipse 6.5 Blue Edition as well. This release introduces a new standard of ALM management and open source capabilities for WebSphere.
依然沒有Struts2,下個版本可能會支持Eclipse3.4了
http://www.sxin99.com
http://www.spitv.net
http://goku.spitv.net
最近學了一些PHP和Ruby的東西,忽然想把這些東西應用做個比較.
首先,我們把Java .Net PHP應用方面占有率做個比較,簡單的把目前主流應用分成兩個大類,一個是企業應用,一個是Web網站應用,下面這個表格是我歸納的,不一定準確,但是能說明一個大概.
應用 / 語言 | Java | .Net | PHP |
大型企業應用 | 多 | 少 | 少 |
中型企業應用 | 多 | 中 | 少 |
小型企業應用 | 中 | 中 | 少 |
大型Web應用 | 多 | 少 | 中 |
中型Web應用 | 中 | 中 | 多 |
小型Web應用 | 少 | 中 | 多 |
從表中可以看到,Java和PHP都有各自擅長的領域,但是.Net卻沒有突出的地方,從占有率來看情況十分尷尬.
我們再來看看技術方面,首先聲明,我對其中每種語言技術都不是很熟悉,只能大概分析一下...
先說說Java,在企業級方面,可以說是絕對的老大,許多企業級技術,開發思想都是由Java發展出來的.缺點是Java開發部署比較麻煩 ,不太適合超小型的項目.
再說.Net,在1.x時代,.Net可以說基本上沒有多少企業級開發的特性,到了3.0,微軟各種框架技術雖然彌補了這些不足,但是相對于Java世界,還是有一定距離. 在Web網站方面,.Net服務器控件的優勢,變成了弱勢,由于服務器空間產生垃圾代碼,并且不方便美工調整,導致在前臺界面要求較高的門戶站點難以使用(雖然有第三方MVC框架,但是沒有IDE支持,體現不出.Net的優勢)
再說說PHP,他的定位非常明顯,就是Web開發,所以有很多適合Web開發的特性,比如部署十分簡單,幾個文件隨便找個虛擬主機扔上去就能運行.在國內因為Discuz , DedeCMS等著名產品的鼎立推廣,PHP在中小型網站開發中有很大的優勢.,最近大量的開源框架出現,給PHP企業開發注入了一些生命力,可以說潛力十足.
綜合以上我們可以看到,.Net定位不太明確,微軟這個想吃那個也想吃,最后沒一個能吃飽吃好..
最后還想說一下Ruby,其實應該說ROR,大家喜歡的應該是ROR的特性,二Ruby是個怪怪的東西,如果沒有ROR框架,我想他也很難出名.因為ROR本身構架不是很復雜,眾多PHP框架可以說都是模仿他的思想來的,而且也學得7 8成功力了,個人認為ROR很難再做大起來,可能是個曇花一現的東西,只是思想新潮大家都來趕時髦學兩下,學到了,大家又都覺得其實也就那樣,其他語言也能做到.
http://goku.spitv.net/
http://www.spitv.net/
http://www.sxin99.com/
| |||||||||
日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
---|---|---|---|---|---|---|---|---|---|
27 | 28 | 29 | 30 | 1 | 2 | 3 | |||
4 | 5 | 6 | 7 | 8 | 9 | 10 | |||
11 | 12 | 13 | 14 | 15 | 16 | 17 | |||
18 | 19 | 20 | 21 | 22 | 23 | 24 | |||
25 | 26 | 27 | 28 | 29 | 30 | 31 | |||
1 | 2 | 3 | 4 | 5 | 6 | 7 |