沒錯, Mybloglog 的確可以去偷 AdSense 的資料. 其實, 掛在同一個網頁下的 Javascript 外掛, 不但可以互相偷資料, 還可以 reuse 對方的 code, 更可以 replace 對方的 code. 不然各式各樣的 API 是怎麼運作的? (eg. Google Maps, Flickr... ). Ajax 玩過火就會有安全上得隱憂的.

GM script 是在整頁 HTML 載入, 並且執行完 body onload 的動作之後才執行. 但是要 hacking Ajax 的網站時常遇到的問題是, 原始網站的 script 經常還沒有跑完, 就輪到自己的 GM script 上場了. 如果你要 hacking 以載入的 HTML elements 那倒還好, 如果要 hacking 對方的 script, 那就麻煩大了, 這是非同步難處理的地方.

Download: AJAX Wrapper for Rojo v1.6.

漂亮的解法應該用一些 event linster 來做, 尤其要 hacking GMail 之流的網站更須如此, 否則 HTML Dom 變來變去, 要 inject dom elements 怎麼辦得到? 但這次就偷懶一下吧, 用個 Javascript Loop 來測試就好了. :p

分享一下寫法:

w.ajaxize = function() {
    if( w.Remote == undefined ) return;
    else clearInterval(ajax_handler);
    w.Remote.execRequest = function(resource, callback, callbackArguments) {
        -- ignore --
    }
}
var ajax_handler = setInterval("ajaxize()", 500);

故事是這樣的:

- TWD67: 台灣內政部在 1997 年之前的舊的 Datum 座標基準
- TWD97: 台灣內政部在 1997 年公告之新的座標基準
- UrMap 用的是 TWD67, 並且是以 TM2 (二度分帶) 座標數值 (詳見此文)
- Google Maps 用的是 WGS84, 並且是經緯度數值 (LatLon, D.d 格式)
- TWD97 與 WGS84 幾乎是相同的, 僅相差數公分 (詳見此文)

因此要將 Google Maps 嵌入到 UrMap 以方便做兩者地圖與衛星圖的比對, 必須進行座標轉換. 轉換的方式如下:

TWD67(TM2) -> TWD97(TM2) -> TWD97(LatLon) 

這部份我用的是在網路上找到的簡易算法 (成功大學水工試驗所大地坐標轉換測試程式)

TWD67<->TWD97 二度分帶二維坐標轉換公式:
A= 0.00001549
B= 0.000006521
X67 = X97 - 807.8 - A * X97 - B * Y97
Y67 = Y97 + 248.6 - A * Y97 - B * X97
X97 = X67 + 807.8 + A * X67 + B * Y67
Y97 = Y67 - 248.6 + A * Y67 + B * X67
PS.僅適用於台灣本島，最大誤差約二公尺,精密測量不適用!

註: 該作者稱最大誤差約兩公尺, 但我自己估測約有十公尺左右的誤差.

TWD97(TM2) -> TWD97(LatLon)

這部份我使用的是 PROJ.4, 這是一套 Unix 下 open source 的座標投影轉換程序 (cartesian coordinates <-> geographic longitude and latitude coordinates). 可以互轉二度分帶 (TM2) 與經緯座標 (LatLon).

API Web Service

因為座標轉換是要用在 GM script 中, 必須以 Ajax 的方式達成. 網路上找到的 TWD67/TWD97 間的轉換工具, 大多是 Web 的 form 介面, 或是 .exe 執行檔, 要在 Javascript 上應用很不方便. 再者 PROJ.4 是 Unix 上的 library, 因此對我而言這項轉換在 Server Side 較容易實作.

既然要支援 Ajax 的方式, 以 Web Service API 的程式介面來提供轉換服務. 我用的是 REST 的簡單格式:

其他參考資料: Taiwan 衛星定位系統 GPS and 座標轉換 TWD67, TWD97, WGS84 coordinate transformations

完工了!! 我把 UrMap 和 Google Maps 這兩家線上電子地圖送做堆了. :)

這支 Greasemonkey script 可以將 Google Maps 整合到 UrMap 中, 自動調整 GMaps 的中心座標以對應目前 UrMap 的中心座標, 並且調到相當的 zoom level. 此外, 在地圖的右上角會即時顯示目前中心座標, 還提供轉換座標為 TWD97 的功能.


之前提到 UrMap 的新操作介面以 Ajax 達成, 使得在 Web 瀏覽地圖變得非常的流暢. UrMap 也提供豐富的地理資訊, 這是 Google Maps 目前在台灣所沒有的. 但是 Google Maps 的優點是有比較清晰的衛星照片, 他的 zoom in level 比 UrMap 還多一級 (100m), 但 UrMap 有全台灣各地相同解析度的衛星照片, 而 Google Maps 只有人口密集的都會區才有高解析度照片, 各有優劣之處. 除此之外, Google Maps 是開放的平台, 有提供 API, 可以自行開發各種應用. 因此整合兩家線上地圖, 可以讓我們對台灣有更清楚的 view.

Download: urmap.gmaps.user.js

在的地圖上方, 會有一個 Google Maps 的按鈕, 可以打開 Google Maps, 並移動到目前 UrMap 的中心座標. 右上角功能列有 "Convert to TWD97" , 可以將目前 UrMap 的 TM2 座標轉換成 TWD97.

開啟後, 就會看到 Google Maps 所提供此區域的衛星照. Google Maps 的衛星照片會非常貼近 UrMap 的, 但是在接近的比例尺下, UrMap 的景物會略大. 而 Google Maps 可再 zoom in 一級來看到更清晰的畫面.

I have been adding some additions to Rojo and keeping this script updated with Rojo. Lately, Rojo slightly changed its HTML layout, so some features of the script failed. I also fixed the compatible problem with Firefox 1.5RC3. Following is the clearance of all additions to Rojo of this script.

1. an Ajax Wrapper for Rojo - replace the remote scripting by iframe request with XMLHttpRequest
2. 'Mark as Read' to each feed - mark the entire feed as read
3. 'Mark as Read' to each article - mark the article as read
4. A toggle to display feed profile - fetch and display the profile of the feed
5. Quick unsubscribing feeds - at the left hand side of feeds navigation and below each article
6. new Read all stories - add 'Read All' after 'Expand All' and 'Collapse All'

Download: AJAX Wrapper for Rojo v1.5. (Greasemonkey script)

Flickr 新增的功能最多. 像 Set 裡多了一些貼心功能, 譬如排列相片順序, Batch Edit 等, 不需要進 Organize 就可以進行. 還有 Lock thread, replace photo 和 printing service 等等.

我常用的 Rojo 也在小改, 但似乎顯得有點力不從心, 常常出槌. 有進步的地方是 Recommended Links, 去 整理統計出來那些 link 最多文章提到; 還有在閱讀單一 feed 的時候可以直接對那個 feed 加 tag, 這不是什麼了不起的功能, 但是 Rojo 搞了很久才修好. 但在 FF 之下卻把 Expand/Collapse All 的功能給搞壞了. 我寫的 Hacking Rojo script 常常出錯, 隔天又自己變好, 就知道 Rojo 背後有東西在修改, 而且通常是還沒改好就急著上線. 但是 Rojo 對 feed/article 組織管理上的理念不錯, 但是在 Web-based Reader 的架構設計上太差, 資料庫效能看來也不是很好, 以後有空再聊.

Yahoo 終於推出了新的 Maps beta 服務, 讓人眼睛一亮.

為了不讓 Google Maps 與 MSN Virtual Earth 專美於前, Yahoo 大幅改進了舊版地圖, 推出了 Maps Beta. 一樣是要著重於使用者操作介面, 無論是拖拉地圖, 放大縮小都變得跟 Google Maps 一樣方便. 不同之處在於, Yahoo! Maps Beta 用的是 Flash, 所以對地圖操作可以提供更細緻的滑鼠控制, 但可惜的是目前只有美國地圖, 也沒有衛星照片.

但真正讓人驚豔的是......

• Geocoding API: 提供地址來找經緯座標的 API 服務
• Map Image API: 提供經緯度或地址來取回地圖的圖檔! 這不得了, 手機業者會愛死這功能! 之前有人 hack google maps 半天才解出 GMaps 的圖檔規則, Yahoo! 這回全部奉送.
• Traffic APIs: 提供某地點的即時交通資訊
• Local Search APIs: 查詢 Yahoo! Local Service. 這應該不用多解釋了吧.

無怪乎 Geobloggers 的作者 Rev Dan Catt 稱 Yahoo! Maps 這次是 Killer App 了. 而 Geobloggers 的動作還真快, 已經馬上改用 Yahoo! Maps API 改寫好了, 可由此處去瞧瞧 Yahoo 版的 Geobloggers.

我想 Yahoo! 大概看了大家 Hacking Google Maps 的過程, 心裡大概有數, 只要是以泛 Ajax 來提供服務(client side computing), 大概免不了遲早要被 hack. 與其讓大家 hacking, 乾脆主動把所有 Web Service APIs 先招了. 這也可以帶動 third party 應用的快速出現. 看來, 競爭線上地圖服務 (even Web 2.0) 的火藥味還真是濃厚啊!

1. 在 menu 裡加了 'update script' , 方便更新 script.
2. 加了相片 'Move to Top' 的功能, 其實就是把在 cart 裡的相片修改 posted date 到目前時間, 於是就相片就可以「置頂」了.
3. 支援 Firefox 1.5Beta2 + GM 0.6.2

ps. 相片置頂功能需要你的電腦時間誤差不能太大, 原則上是把相片 posted date 設成 (now - 5min). Flcikr 不接受 posted date 設成未來時間.

Download: flickr.batch.user.js

Flickr is lacking of creating a list of arbitrary photos for batch operations. This script provides a "shopping cart" for you to collect your photos to process. After you added a number of photos in cart, you can edit as a batch, make an album, a slideshow, or a mosaic. Items in cart will be saved in greasemonkey storage and will be remembered while you're visiting different pages in flickr.

Features:

1. A cart to collect photos you select, up to 100 photos
2. A checkbox attached on the upper-right corner of each photo
3. Editing photos as a batch, beyond sets, tagged photos, or date-based photos
4. Connecting to external flickr tools, such as Flcikr Album Maker, Photo Mosaic, or Slideshow.
5. Working fine with "GM: Batch Enhancer"

Special thanks to fd (John) for his permission to feed the list of photos to his flickr toys. (slideshow and mosaic)

Download: flickr.batch.user.js

I've written a new GM script called "Ajax Photo Blogging." It's not an improved version of official "Blog this" tool, instead, I create a new one in Ajax approach to let you blog faster and easier.

The features of the tool:

1. Blogging and posting in Ajax way in background.
2. Posting to your blog via XMLRPC by calling GMxmlhttpRequest of greasemonkey.
3. Using MetaWeblog API. Working fine and testing in Movable Type 3.2 now.
4. Adding the URL of new post to the photo description or comment, depend on if you are the owner of photo or not.

The pros -

1. No need to save your blog password in Flickr.
2. Blogging and commenting at one-click.

The cons -

1. Storing your blog password in local machine causes inconvenience when not using your own computer.
2. You need to know the detail tech info of your blog, eg. XMLRPC endpoint URL, blogid...

I only test under my blog environment now. Mine is Movable Type 3.2. I believe all MT series will work fine. If any of you are interested in this script, please have a try and let me know the result. Your feedback is appreciated.

ps. The pieces of code to add comment and description are contributed by steeev in my GMiF project. Thank you.

Download: flickr.blog.user.js
Discussion: Flickr Hacks Group in Flickr

今天在瀏覽器端 Javascript 能作的事兒實在太多, 基本上模擬一個使用者去操作 Web 介面是完全可行的, 一旦在瀏覽器端的 script 能夠開始執行, 大概就擋不了什麼了, 而如果又是在 logged on 的狀態, 使用者權限能做的事大概都能夠做. 所以第一關要防堵的就是不讓使用者 inject 能夠被 invoke 的 script. MySpace 當然不允許使用者 script, 作者的方法是在 <div> style 的 background url 裡塞進 script. 果然令人意想不到.

看了之後的心得是, 萬惡的 Javascript 能幹的壞事兒又添了不少.

What is Yahoo! Site Explorer?

The Yahoo! search database contains detailed information about the structure of the web. In addition to the web pages themselves, the database stores information about links among pages, and uses that information (as well as additional algorithms) to gauge the popularity of a given page.

Site Explorer gives you access to this information so you can learn about a site. To explore a site, you submit a URL using a search box, just as you would for a normal web search. You can then click links on the results page to see detailed information.

我試用了這幾個重要的搜尋服務中, 似乎只有 Yahoo Site Explorer 有提供比較像樣的 Web Services API. 我利用 Yahoo 這個 API 寫了一個 Scriptlet, 可以嵌在任何網頁中, 透過 Yahoo API 搜尋所有連至該網頁的 inbound links. 這個 Scriptlet 以類似 Ajax 的方式在背景呼叫 API, 傳回結果顯示在 Scriptlet 嵌入的位置. 有興趣者歡迎試用.

<script src="http://webdev.yuan.cc/search/siteexplorer.js">
</script>

搜尋結果會放在一個 <div> 內, <div> 的 id 是 "Yahoo_Site_Explorer", 所以您可以用 CSS 自訂呈現的樣式. 範例如下:

#Yahoo_Site_Explorer {
   width: 200px;
   padding: 5px;
   border: 1px solid #FFFFFF;
   color: #333;
}
#Yahoo_Site_Explorer span:hover {
   color: #36414d; 
   text-decoration: underline; 
}

安裝好之後, 在你的網頁會出現 "Click to Search via Yahoo Site Explorer..." 的文字, 按一下這段文字就會開始搜尋. 如果想要網頁載入後自動開始搜尋, 請將網頁或 Blog 模版的 <body> 改成下列的寫法:

<body onload="YuanCC.search()">

實際的範例在本站右邊的 sidebar 可以看到. 這支 script 寫的時候遇到一些 Firefox 與 IE 相容性的問題, 並且還要應付 XMLHttpRequest 的安全性問題, 所以程式有點雜亂. 歡迎大家測試, 如果使用上遇到任何問題請隨時告知. 下一篇會詳細介紹調整這支 script 的一些參數, 如搜尋等待時間, 指定搜尋網址, 傳回搜尋結果筆數等.

而 Ajax 的另一面砍向了 Ajax 網站自身. Ajax 是先天的 Open Source, 採用 Ajax 的網站都等於無條件的將原始碼奉送給大眾. 以 Ajax 為主要網頁呈現技術的網路服務, 必須自己有不可取代的核心資訊在背後, 否則 Ajax 無非就是一張建築藍圖, 一五一十的告訴外界設計上的秘密. 透過藍圖, 任何人都可以取得網站背後所提供的資訊, 無論有沒有開放 API, 業餘開發者甚至競爭對手都可以取得伺服器端的資料. Google Maps 的 hacking 和 Flickr 與 GMail 的一堆 Greasemonkey scripts 就是個例子.

In Rojo, you can unsubscribe feeds only within two pages, the page of managing your feed list or the one of viewing the feed profile. Now the rojo.ajax.user.js script injects quick links to let you unsubscribe feeds any time. The response time of unsubscription is very fast due to the calling to unpublished Rojo API (RPC). :)

Download: AJAX Wrapper for Rojo v1.4. (Greasemonkey script)

In the left hand side of feeds navigation, there's a new icon heading each feed. You can click the icon to unsubscribe the corresponding feed.

Beside, in the list of stories, there's an additional link next to "Mark this feed as Read". You can also click to unsubscribe the feed.

Previous articles:
[Ajax] Hacking Rojo - Adding bits to feeds in Rojo
[Ajax] Hacking Rojo - Ajaxize more of 'Mark as Read'
[Ajax] Hacking Rojo - Ajaxize 'Mark as Read' function
[Ajax] Hacking Rojo - Slow Response of Rojo
[Ajax] Hacking Rojo - an Ajax Wrapper for Rojo
[Ajax] Hacking Rojo - Rojo is not Ajax?

越來越看不懂一堆人整天鬼扯的 Web 2.0 了. 每次網路上一有什麼新玩意兒, 就開始想像一個新的時代來到了, 好像 Internet 會從此脫胎換骨似的, 是不是成天玩網路的人都有先天過份樂觀症候群? 看到異想天開寫了 Web 3.0, 讓我笑了好久. 我想應該直接飆車到 Web 5.0 or Web XP 比較過癮點.

也許是大家悶久了, 總要創些名詞來說說嘴, Ajax 是還算好的, 雖然沒有新鮮貨, 至少有個明確的定義. Web 2.0 連個定義都是模糊的, 只看到一堆人只好開始用舉例的方式說這是 web 2.0 , 這是 web 1.0, 那不是 web 2.0 諸如此類的, 只會以分類法來定義新名詞, 卻又說不清個所以然. 那我來給個定義好了, 管你有沒有互動, 管你是不是 Ajax, 管你是不是 Read/Write, 管你是不是去中心化, 凡是能幫我聚集人氣能賺大錢的網站, 通通叫做 Web 2.0! 這不就得了?

我始終覺得這是 Blog 風行以後的後遺症, 說話的人多了, 就聽不清真相了. 專家說話也不聽, 每個人都有自己的詮釋, 大家都爭著說話, 說一些言不及義的五四三. 最令人憂心的就是炒熱了一個名詞, 而這個名詞卻沒有實質定義與內涵, 然後卻成為了投資者的重要參考依據; 就像台灣一窩瘋的蓋 BSP 一樣, 每天電視新聞下面的跑馬燈就開始跑主播部落格的網址, 每家報紙也都跑出部落格, 然後台灣的網路業者也都很糟, 都沒什麼創新理念, 只會跟在人家屁股後面.

最好 Web 2.0 不要給我弄進教科書去, 否則我絕對要去靜坐抗議!

碎碎念完了.

Rojo is lacking of some designs of user friendly. Why am I saying that? Sometimes we need to make an unnecessary click to get some basic but useful information of a feed. While reading stories of a feed, we probably want to take a look at the profile of it, or we also need to link to its original site. Furthermore, we would like to know the number of subscribers, unsubscribe, or rename the feed. All the stuff is in the profile of the feed, and need a click to get it.


The worse is still the slow response of Rojo. Loading a new page requires not only to fetch from server, but also needs extra time for browsers to render it. Now the script rojo.ajax.user.js v1.3 adds some bits to it. It fetches the profile of the feed in background, then displays a toggle below the title of feed. Click the toggle will show the information on the feed in Ajax way.

Download: AJAX Wrapper for Rojo v1.3 rojo.ajax.user.js

Previous articles:
[Ajax] Hacking Rojo - Ajaxize more of 'Mark as Read'
[Ajax] Hacking Rojo - Ajaxize 'Mark as Read' function
[Ajax] Hacking Rojo - Slow Response of Rojo
[Ajax] Hacking Rojo - an Ajax Wrapper for Rojo
[Ajax] Hacking Rojo - Rojo is not Ajax?

應使用者建議, 把 LfVr 的 tags 顯示改成這樣.

這是一個 Greasemonkey script 可以把聯合新聞網改成 Ajax 的方式來載入新聞. 不必再重新載入整個 HTML 頁面. 雖然 UDN 的廣告都已經被我清除乾淨, 速度已經很快了, 但是這個 Ajax 的小實驗還是很有趣的. 方法就是用 XMLHttpRequest 來載入新的新聞 HTML 檔, 然後截出新聞本體的部分來取代現在的頁面. 實驗後可以證明, 一個網站的速度, 跟全頁載入的效率很有關係. 這牽涉到網頁設計用到的元件, 如要載入的圖形或 Embed/Plugin, 還有頁面 Layout 的複雜性等等. 如果一個以新聞資訊為主體的網站在每次轉換頁面都需要重複載入這些元件並且重新 Rendering 頁面, 那浪費的時間是不少的.

目前這個 script 能處理的 UDN 新聞有國內要聞, 兩岸國際, 及地方新聞三大類. 要用 Ajax 載入新聞時請按新聞標題前新增的這個小 icon .

Download: udn.ajax.user.js

Last time I have Ajaxized a 'Mark as Read' on a single feed to move the HTTP request to background by calling XMLHttpRequest instead of bringing to a new page. The counters of unread entries are reset on LHS menu. This time I extend the work to each single story and the feed below the story entry. That means you can now mark a story read as well as the feed of a story. See the screenshot above.

For each story, you can now do expand/collapse, mark as read, or both on it. For the feed of a story, you can also mark it read. This makes you much easier to mark a feed read without going to the page of that feed.

Download: AJAX Wrapper for Rojo v1.2 rojo.ajax.user.js

Blogs talking about this:
Someone Hacked Rojo Using Greasemonkey!
Speed up Rojo using GreaseMonkey- Firefox Users only

Related Articles:
The Blog Herald - Rojo reviewed

很快的裝了一下, 又看了 gslin 遇到這個問題, 實在覺得 Icerocket 提供 scriptlet 的方法有點畫蛇添足.

http://blogs.icerocket.com/citations.php?f=text
&q=http://blog.yuan.cc/ck/

傳回的內容不是正統 Ajax 的 XML, 而是一段 HTML. 看來要應用應該不是那麼複雜.

我改寫了 Icerocket 的 cit_client.php, 讓事情簡單點.

<?
$q = isset($_GET['q'])?$_GET['q']:"";
$str = file_get_contents( 
    "http://blogs.icerocket.com/citations.php?f=text&q="
    .urlencode($q));
echo "document.write(\"$str\");\n";
?>

用法:

<script
 src="http://blog.yuan.cc/cit_client_js.php?q=http://blog.yuan.cc/ck/">
</script>

結果就直接在這裡 --> 把 script 直接塞到要放 "54 Linking Posts" 的位置去就好了.

第二個是寫一支 cit_client_dom.php

<?
header('Content-type: application/x-javascript');
$q = isset($_GET['q'])?$_GET['q']:"";
$ref = isset($_GET['ref'])?$_GET['ref']:"";
$str = file_get_contents(
    "http://blogs.icerocket.com/citations.php?f=text&q="
    .urlencode($q));
echo "$ref.innerHTML = \"$str\";\n";
?>

用法一:

<script 
src="http://blog.yuan.cc/cit_client_dom.php?ref=elm&q=http://blog.yuan.cc/ck/">
</script>

用法二:

<script> 
    var elm = document.getElementById('elm');
    var js = document.createElement("script");
    js.language = "javascript";
    js.src = "http://blog.yuan.cc/cit_client_dom.php?ref=elm&q=http://blog.yuan.cc/ck/";
    document.body.appendChild(js);
</script>

這是比較高級的應用, 如果你的 blog 有用到一些複雜的 DHTML 時這會很方便. 就是先把 DOM Element 的 reference 抓到(getElementById) 或造出來 (createElement), element 的 reference 是 elm, 然後傳給 cit_client_dom.php, 之後這個就會 elm.innerHTML 就會被塞進 "54 Linking Posts" 這玩意兒了. 比較常用的 container 可以是 <p>, <span> 兩種.

The script 'rojo.ajax.user.js' is now version 1.1 and has the following features:

1. Override the Remote object(remote scripting) by an Ajax wrapper. 2. Mark as read is now Ajax and reset the unread count on the LHS menu.

Download: rojo.ajax.user.js

Ajax.Mark_as_Read = function() {

    var markasread = document.getElementById("markReadLink");
    if( markasread ) {
        var url = markasread.href;
        markasread.href = 'javascript:;';
        var callback = function() {
            var li = document.getElementsByTagName('li');
            for(var i=0; i < li.length; i++) {
                if( li[i].className == 'selected subscription unread' ) {
                    li[i].getElementsByTagName('span')[0].innerHTML = '';
                }
            }
        }
        markasread.onclick = function() {
            Remote.execRequest(url, callback, null);
        }
    }
}

但是撇開 Remote Scripting, 另一個慢的原因是在架構設計, 和使用者介面採用的 Ajax 還不夠多所導致. 簡單說, 就是頁面切換次數太頻繁. 每一次的切換網頁(網址會改變) 就是要連回 HTTP 伺服器重新產製一次頁面, 這包含了資料庫查詢, 建立該頁面左側的 feeds 清單, 以及頁面中間的 entries 清單. 中間的 Entries 清單可不只是標題, 還有 entry 的內容都一併傳回, 這個動作可以擱置到後來以 on-demand 的方式來取回, 應該可以加速不少. 其次是有太多的操作上的功能應該以 Ajax 的方式來完成, 譬如 Mard as Read, Show Read & Unread, 都是 Ajax 的強項, 要多多利用才是.

上篇我簡單寫了一個 Wrapper, 以 Ajax 來取代 Remote Scripting 的 Greasemonkey script. 能改善的效能有限, 原因就在於太多的功能需要重新連回伺服器做頁面轉換. 其實, 很多地方都可以 Ajax 來達成, 既快速又省頻寬.

補記:
呵呵, 發現不是我一人嫌 Rojo 慢....

As we already knew, Rojo uses a lot of DHTML + Javascript techniques to enhance the user interface. Despite Rojo has the modern design of tagging and social share, it seems not to be an Ajax approach I talked in my previous post, "Hacking Rojo - Rojo is not Ajax? ". Rojo retrieve asynchronous data by remote scripting with iframe, not by calling XMLHttpRequest. There would be a little bit slower when using remote script instead of XMLHttpRequest. Therefore I did a small experiment to replace the iframe remote script by the Ajax way. The Greasemonkey user script can meet my need to override the methods of Remote object in Rojo.

This Greasemonkey user script is a wrapper for Rojo to replace its iframe request by the XMLHttpRequest function. The data retrivial will proceed in background, so the browser won't be seen in loading pages any more. After installing the script, the response of using Rojo should become faster.

Download: rojo.ajax.user.js

Remote.execRequest = function(resource, callback, callbackArguments) {
    //NOTE: we need to prevent corruption here due to multi-threaded IO and
    //non-blocking UI controls in IE/Mozilla

    this.callback = callback;
    this.callbackArguments = callbackArguments;
    this.waitingForResponse = true;
    this.changeIFrameLocation(resource);
}

Remote.iFrameOnLoad = function() {

    if ( this.callback != null ) {
        var currentCallback = this.callback;
        var currentCallbackArguments = this.callbackArguments;
        this.callback = null;
        this.callbackArguments = null;
        this.resource = null;
        this.waitingForResponse = false;
        if (this.requests.length > 0) {
            var nextRequest = Util.shift(this.requests);
            this.waitingForResponse = true;
            this.execRequest(nextRequest.resource, nextRequest.callback,
                             nextRequest.callbackArguments);
        }
        var iframeContents = Remote.getIFrameContents();
        if (currentCallbackArguments == undefined ||
            currentCallbackArguments == null) {
            currentCallbackArguments = new Array();
        }
        currentCallbackArguments[currentCallbackArguments.length] = iframeContents;
        currentCallback.apply(null, currentCallbackArguments);
    }
}

Now we can override the above two methods by the following new methods with a real Ajax XMLHttpRequest call.

Remote.fakeiFrameOnLoad = function(result) {
    if ( this.callback != null ) {
        var currentCallback = this.callback;
        var currentCallbackArguments = this.callbackArguments;
        this.callback = null;
        this.callbackArguments = null;
        this.resource = null;
        this.waitingForResponse = false;
        if (this.requests.length > 0) {
            var nextRequest = Util.shift(this.requests);
            this.waitingForResponse = true;
            this.execRequest(nextRequest.resource, nextRequest.callback, nextRequest.callbackArguments);
        }

        var iframeContents = result;
        if (currentCallbackArguments == undefined || currentCallbackArguments == null) {
            currentCallbackArguments = new Array();
        }
        currentCallbackArguments[currentCallbackArguments.length] = iframeContents;
        currentCallback.apply(null, currentCallbackArguments);
    }
}

Remote.execRequest = function(resource, callback, callbackArguments) {
    this.callback = callback;
    this.callbackArguments = callbackArguments;
    this.waitingForResponse = true;
//    this.changeIFrameLocation(resource);

    var xmlhttp = new XMLHttpRequest();
    xmlhttp.onreadystatechange = function() {
        if (xmlhttp.readyState==4) {
            if (xmlhttp.status==200) Remote.fakeiFrameOnLoad(xmlhttp.responseText);
        }
    }
    xmlhttp.open('GET', resource, true);
    xmlhttp.send(null);
}

之前說到開始嘗試 Rojo, 試用了幾天之後有一些心得.

優點:

1. 最大的好處還是 Tag. :) Rojo 可以 tag feeds, 對於 feeds 很多的人是一大福音.
2. Rojo 也可以為單篇文章加 tag, 這適合做保存文摘, 也可以方便去搜尋別人 tag 的相關文章.
3. 介面設計上有些 DHTML 的互動, 不牽涉 data retrieval 時的操作速度可以加快.

缺點:

1. Rojo 對中文的支持有點問題, 如果不小心加了中文的 tag, 訂閱的 feed 會無法刪除 tag, 而且左邊的 tag 列表裡的中文 tag 展開以後, 換頁不會記住已經展開的狀態. Feed 的 title 如果是中文的話, 也顯示不出來. 除此之外, 其他對於中文的內容都沒有問題.
2. 一些使用介面上還不夠好, 為 feeds 加減 tag(s) 只能在 Manage feeds 的網頁中做, 無法在閱覽的時候做, 不太方便.
3. 速度有點慢. 這點牽涉到 Ajax 技術上的問題, 是後面的主要討論內容.

我先前很快的就說 Rojo 使用了 Ajax 的技術, 現在看來是有些疑問的. 依照 Ajax 一詞最早的出處 "Ajax: A New Approach to Web Applications" 所定義:

Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:

* standards-based presentation using XHTML and CSS;
* dynamic display and interaction using the Document Object Model;
* data interchange and manipulation using XML and XSLT;
* asynchronous data retrieval using XMLHttpRequest;
* and JavaScript binding everything together.

首先在 Ajax 的定義上便有爭議 (如果 Ajax 可以有定義的話), 這篇 "Ajax, promise or hype?" 便質疑這部分. 是否 Ajax 一定要使用 XML 或 XMLHttpRequest, 甚至 XSLT? 而我認為最關鍵之處在於是否具備了 Asynchronous Data Retrieval 的特性.

影響 Web Application 速度最劇的, 不僅在於伺服器是否有足夠的資料處理能力, 層層的資料傳遞堆疊恐怕是更大的殺手. Asynchronous Data Retrieval 可以讓 DHTML 與使用者互動時動態載入資料, 再產生出想要呈現的 HTML 外觀介面. 但是如果用了不好的 Asynchronous Data Retrieval 方法, 恐怕在反應速度上要大打折扣.

Rojo 使用的其實是一個名為 Remote Scripting 的技術, 這項技術最早在 "Remote Scripting with IFRAME" 中被提出. 這種方法會在網頁中放一個隱藏的 iframe, 然後利用這個 iframe 去擷取遠端的資料. 可以這樣做的原因是因為在同一個 document 之下的 frame, 都可以用 DOM/Javascript 來彼此控制存取, 因此透過一個 iframe 便可用來當作與遠端資料交換的 channel, 而不需要轉換 www 頁面. (轉換一個 www 頁面其實是非常慢的, 因為除了要 web server 重新產生新的 HTML 之外, 瀏覽器還得 render 並造出整個 Dom Tree.)

來瞧瞧 Rojo 中的 Javascript 片段中的 Remote object:

Remote.setup()
Remote.exec()
Remote.execRequest()
Remote.iFrameOnLoad()
Remote.getIFrameContents()
Remote.changeIFrameLocation()
Remote.callback()
Remote.iFrame
Remote.requests
Remote.waitingForResponse
Remote.callbackArguments

用 iframe 這種方法似乎不是很理想, 在速度上還是太慢. 因為一個 frame 之內仍然包含一個 document object, 在這個 document 之下還有 Head, Body 等 object, 最後要從 Body object 來取回其 innerHTML 內所含的資料. 而利用 frame 送出一個 HTTP request 給遠端的伺服器, 對規劃不佳的 web server 而言, 仍可能透過一般的 HTTP server side engine 來產生回應. 這類只需 Data Retrival 的 Web Service, 大多是資料庫查詢就可得到的結果, 大可不必透過一般的 Web Server, 直接使用 XML Server 等 lightweight HTTP server 即可.

最後 Rojo 究竟算不算 Ajax 的應用? 如果依照嚴格的 Ajax 定義, 那應該不算. 如果是以 Asynchronous Data Retrieval 的精神來論, 可能只能說符合這種設計精神; 但在速度效能的表現上, 沒有充分的發揮 Ajax 能達到的快感. :)

我試著將我在 Bloglines 的 feeds 匯出成 OPML, 再匯入到 Rojo 去, 我訂閱的 feeds 就全部轉過去了, 一切都很順利; 而且匯入到 Rojo 後, 還會依照 Bloglines 自動設好相同的 feeds 分類. 是很好的 Bloglines 替代品, 再也不用擔心 feeds 不見的事件重演了.

看來一切都很不錯, 試用一陣子看看再決定要不要轉台. :)

Rojo 的網址是 http://www.rojo.com/

我改良了之前寫的 Toggle Recent Comments in Flickr Photostream, 這次可以把在 Flickr 的 comments 放進 Blog 中.

擁有 Blog 的人很多也喜歡 Flickr, 因為存放空間是無限大而且免費, 而 Flickr 也鼓勵使用者可以在自己網站連結他們的照片. 其實 Flickr 本身就是一個龐大的社群, Blog 自己則是一個小的社群, 這兩群使用者有時候是重疊, 有時則不盡然. 很多人都在自己的 Blog 放上了 Flickr badge, 透過這個 script, 可以在 Blog 裡嵌進一個 Flickr Comments Box, 可以讓讀者看到格主在 Flickr 上的相片留言.

安裝與使用法則類似 Flickr Badges, 還可以自己調整 CSS 來搭配 Blog 的外觀.

I create a new script that can load your recent flickr comments and embed into your blog or web site.

Bloggers love flickr so much because of the free and unlimited space. The community of flickr usually overlaps the readers of our blogs. We already have the flickr badges to show our photos. Now we can put a flickr comments box in the blogs.

This script, a variation of 'Recent comments in photostream', can embed flickr comments in your blog.

Live demo:

Usage:

Control Parameters:

....... HTML head .......
<script>
// your flickr userid (nsid)
flickr_nsid = '62869273@N00';	
// the title
flickr_comments = 'My Flickr Comments';	
// the number of entries to show, max is 10
flickr_entries = 10;
// open comments box by default
flickr_open = false;
</script>
....... HTML head .......

....... HTML body .......
<script src="http://webdev.yuan.cc/flickr/flickr.comments.js"></script>
....... HTML body .......

<style>
#flickr_comments {
        width: 200px;
	padding:5px;
	border:1px;
	background-color:#eeeeee;
}
#flickr_comments span {
	font-size: 13px;
	font-family: Verdana, Arial, sans-serif;
	text-transform: uppercase;
}
#commentList { 
	margin:0px;padding:0;
}
#commentList ul {
	margin:3px;
	padding:0;
	min-height:72px;
}
#commentList ul img { 
	float:right;
	width:70px;
	border:0px;
	border-color: #ffffff;
	margin:5px;
}
#commentList ul p {
	padding-top:2px;
	padding-left:2px;
	padding-right:20px;
	padding-bottom:0px;
	color: #666666;
	font-family: Verdana, Arial, sans-serif;
	font-size: 11px;
}
#commentList ul a {
	color: #666666;
	font-family: Verdana, Arial, sans-serif;
	font-size: 11px;
}
</style>

如此一來, 似乎可以改寫 Lightweight flickr Viewer 成 bookmarklet 的版本來避免此問題, 而且在切換 flcikr & LfVr 時, 連 IE 也可以使用, 不需要再透過 Greasemonkey 了.

技术:
1. 客户端AJAX，或站内AJAX：略.
2. 服务器端代理AJAX：略.
3. 客户端代理AJAX：这个想法真的很棒，太有创意了。本篇介绍的这个工具就是利用了这一条。我在安装那段第二条中写道：打开del.icio.us随便进入一个页面，为什么要必须打开一个del.icio.us的页面呢？因为只有打开这个页面你的浏览器当前域就属于del.icio.us了，这时候点击快捷栏上的书签时调用AJAX其实就赋予了代码的del.icio.us域的权利，所以才能实现从web1取代码后和web2进行通讯(以往这就属于跨域了)，关键就是先要打开一个del.icio.us的页面

重點就在於 3. 客戶端代理 AJAX 了. 原先 LfVr 算是使用了 FlickrJS 的服務器端代理 AJAX 的技術, 透過 proxy.flickr 來轉介 XML request.

相關網站:

Yuan.CC Web Experiments
LfVr
del.icio.us
del.icio.us direc.tor

這個前一陣子寫好的程式, 擱了好久都沒介紹. 原因是應該要好好談談, 但是一直沒時間, 因為內部牽涉的技術跟痛苦經驗頗多的, 想紀錄的東西一多就懶得下筆了.

先來個摘要吧,

This is a pure Javascript Flickr viewer called "LfVr". The viewer is based on FlickrJS made by Gustavo Marin.

This viewer is designed by ajax approach and runs fast. I exploited most Flickr APIs to build the viewer with most frequent used funtionalities. You can search and browse photos by users, contacts, photosets, tags, or groups.

其實動機就是想快速瀏覽相片, 我又對新鮮技術有點好奇, 再加上 Flickr 開放 API, 我很早就想試試 Ajax 的 Web App 的寫法了, 於是就來試試看.

LfVr 是個怪字, 反正也是學一下 Flickr 的怪怪, 他偏偏要在字尾加個 r 耍酷, 讓人念不太出來, 常錯讀成 k-er 的音. 而 LfVr 沒有母音, 更怪吧, 反正我耍無聊也不是一兩天的事了. 有趣的是, 我去 Google 跟 Yahoo 搜尋 LfVr 的時候, Google 把我在 Flickr 的 Flickr API 上發佈的 LfVr 列為第一, LfVr 網站則是第二, 喂喂喂, 我可是官方網站耶!! 不要給我留言談 Google Sitemaps, 我已經知道了, 但是懶得安裝. 倒是 Yahoo 精準的把我的網站排在第一, Goston's Blog 的文章排第二, 再來是 Furl, 至於 Flickr API 的討論, 被遠遠拋到第二頁去了. 怪了, Flcikr 不是被 Yahoo 買了嗎? 搜尋引擎沒有給 Flickr 多一點分數嗎?

回到正經的話題, 對於現在開放 API 的一些網路服務, 其實是很有趣與值得觀察的現象. 對一個已經很成功的服務來說, 這種模式有效的吸引了很多開發者參與, 也做出了很多有趣有用的東西. 只是當開放的 API 非常豐富的時候, 是否會影響自己的利基? 當 Third Party 做的功能超越原始站時, 原始服務的優勢又在那裡? 另一個有趣的應用則是 Greasemonkey, 當使用者端可以自行修改變更主站的型態, 影響會有多大? 影響會大到原始網站開始反彈嗎? 這一篇 Gmail正式向 Greasemonkey 宣戰點出了這個話題. 將來的網路服務會是什麼型態? 跟使用者又如何互動? 使用者究竟有沒有完全的自主權? Let's wait and see.

在 Flickr 中要看誰有對自己的照片 comments 的方法, 除了一張張照片進去看之外, 比較方便的就是從這裡去看: http://www.flickr.com/recent_comments.gne ; 在這個畫面之下則有 RSS/Atom feeds 可以訂閱. 如果不訂閱 RSS, 要特定跑來這個網址有時還挺麻煩的, 因為他只在 Flickr 的首頁有放連結, 而不是在每個畫面都有.

但是這個顯示 comments 的畫面太長了, 不是很美觀. 於是我就改寫了一下, 要看 comments 時, 要按一下 "Recent Comments" 才會顯示出來, 再按一次就會關閉.

下載: flickr.comments.toggle.user.js

更新: 上面那個 GM user script 是更新版, 先前的有 bug, 跳到第二頁以後 Recent Comments 的 Link 出不來; 之前有安裝的朋友請重新安裝.

在上一篇提到的 FlickrJS 可以很容易寫出 Ajax 的 Flickr 網頁程式, 於是我牛刀小試寫了兩個自己想要的 Flcirk Badges. 可以直接在網頁上看下一張相片而不需重新 reload 網頁. 速度很快, 非常 light-weight. 程式碼還是放在我的 Yuan.CC Web Experiments 網站中, 有興趣者歡迎去試試.

Defining Ajax

Ajax isn't a technology. It's really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:

• standards-based presentation using XHTML and CSS;
• dynamic display and interaction using the Document Object Model;
• data interchange and manipulation using XML and XSLT;
• asynchronous data retrieval using XMLHttpRequest;
• and JavaScript binding everything together.

Ajax 的全名是 Asynchronous JavaScript + XML, 它稱不上是新技術, 只是一種新的 Web Application 設計方式, 整合了過去數種早已存在的技術. 但是這樣的 Web 應用程式卻很 lightwiehgt, 因為許多的動作不需連回原來的 web server 產生新網頁, 而只需 XMLHttpRequest 取回 XML data, 便可以利用 Javascript 重新安排網頁元素, 呈現出 Desktop Application 般的互動效果. 在市場上, 這種設計技術由 Google 開始大量產品化, 像是 Gmail, Google Groups, Google Suggest, and Google Maps 都是採用此種方式設計出來的. 不過要澄清的是, 嚴格的說, 不能說是 Google 採用了 Ajax 的技術, 因為是 Google 先以這種 approach 設計產品, 而後才有 Ajax 這個名詞被定義出來. Cradit 還是要分清楚的. 當然, Google 是否是第一個採用這個 approach 我也不知道, 但至少是 Google 帶動的流行.

上星期在閒逛 Flickr API 的討論區時, 看到了 FlickrJS 這樣的作法. 它是一個 wrapper, 把呼叫 flickr.photps.xxx 之類的 Flickr API 給替換掉, 這個 wrapper 會將呼叫 flickr api 的動作回傳給 proxy server, 再把由 proxy server 取回的 XML data 交回 caller. 為什麼要這樣做? 為何不直接用 Javascript call flickr api service? 因為瀏覽器的安全性設計, 是不允許 Javascript 執行 out of site 的 http request, 於是 Javascript 英雄無用武之地, 無法得到使用 flickr api 的好處.

在 Flickr API 的文件中, 列了許多連結 flickr 的開發工具, 不過幾乎都是 server side 的程式庫. 而 FlickrJS 卻是 client side 的 Javascript library. 使用了 FlickrJS 之後, 就可以輕鬆的用 Javascript 寫出一個 Ajax design approach 的 Flickr 網頁應用程式.