新手请教：如何安装插件
心情驿站
请教一个初级问题；
看到网络上有很多不同版本的TiddlyWiki
还有一些专门的插件，我的问题是如何把这些好的插件安装我所使用的TiddlyWiki中呢，
比如这里的一个插件http://www.tiddlytools.com/#SinglePageModePlugin
我不知道如何加入到我正在使用的版本中ptw-2.2.0-beta4-070319，
这个压缩包中有个plugins 目录；是不是默认的已经都安装好的？
BramChen
大家好；我是一个新人，
请教一个初级问题；
看到网络上有很多不同版本的TiddlyWiki
还有一些专门的插件，我的问题是如何把这些好的插件安装我所使用的TiddlyWiki中呢，
比如这里的一个插件http://www.tiddlytools.com/#SinglePageModePlugin
以 SinglePageModePlugin 為例，可選擇不同的安裝方式：
在瀏覽器中開啟你的 TW 文件，
1) TW 2.2.0 建議採用此方式安裝
a.點擊右上方之「控制台」（backstage）之「導入」（import）
b.「指定伺服器類型」: 請選擇 「file」
c.「請輸入網址或路徑」:輸入 http://www.tiddlytools.com/，點擊 「開啟」
d.完成與伺服器連線後，再點擊「開啟」
e.勾選列表中的「SinglePageModePlugin」
f.點擊「導入」、「完成」後，關閉「控制台」
g.儲存變更後，刷新頁面，即完成安裝。
此安裝方式，可利用「控制台」的「同步」功能，線上更新套件，這是 TW 2.2.0 的眾多新功能之一。
2) 傳統的 TW 套件安裝方式
a.將 http://www.tiddlytools.com/#SinglePageModePlugin 的 內容剪貼複製至新增的文章 （tiddler）中，將該文章的標籤設為 systemConfig ，文章標題則建議輸入該套件名稱。
b.「完成」編輯後，「儲存變更」再刷新頁面，即完成安裝。
3) 載入外部 js 檔形式的套件
a. 在預設文章 MarkupPreBody 中輸入： <script type="text/javascript" src="pathto/YourPlugins.js"></script>
（其中，pathto 為 YourPlugins.js 套件所在之相對路徑名稱， YourPlugins.js 為套件檔名）
b.「完成」 MarkupPreBody 的編輯後，「儲存變更」再刷新頁面，即完成安裝。
c.範例請參考下列說明中的 MarkupPreBody 內容
我不知道如何加入到我正在使用的版本中ptw-2.2.0-beta4-070319，
这个压缩包中有个plugins 目录；是不是默认的已经都安装好的？
解壓後，在你的瀏覽器中開啟 index.zh-Hant.html，
查看 MarkupPreBody 裡頭即安裝外部套件的方式，
新增一 tiddler ，其標題可自訂，輸入 tiddler 內容： <<listExtCode>> ，
完成後可看到已安裝之步步載入之套件。
--
Bram Chen
Website: http://ptw.sf.net/
心情驿站
另外请问 如果使用一段时间以后，不想要这个插件了；如何删除？
再有；载入外部 js 档形式的套件 ，与内嵌方式；两者有何的优劣如何？
BramChen
> 如果使用一段时间以后，不想要这个插件了；如何删除？
1) 將標記為 systemConfig 的 tiddler 直接刪除，或是可以自「控制台」 的「套件管理」停用套件。
2) 自 MarkupPreBody 載入的套件，可在欲停用的套件前後加入「<!-- -->」 的HTML註解語法，例如：
<!--
<script ...></script>
<script ...></script>
....
-->
或直接刪除對應之 <script ... ></script>
再有；载入外部 js 档形式的套件 ，与内嵌方式；两者有何的优劣如何？
後者相容性高，未來 TW 2.2.0 釋出後，套件更新更簡便。
若有多 TW 文件使用許多同群套件，或 debug 套件時，可考慮前者。
相關討論可參考：
http://groups.google.com/group/PrinceTiddlyWiki
（輸入搜尋條件：「由外部檔案載入plugins的好處」）
oc
以減少下載負擔，加快啟動速度？
oc
MilchFlasche
BramChen
2007/3/29, oc <blo...@gmail.com>:
Bram，一直在本機使用TW，所以對js分離版本不是很熟，我想請教如果這些個別分離的套件可以設定哪些是啟動必備，哪些可以等候呼叫才下載，好像可
以減少下載負擔，加快啟動速度？
但「加速」或「優化」通常是有「前提」的，並非絕對。
若分離的 js 套件的載入宣告是放在 MarkupPreHead 或是 MarkupPostHead ，套件裡的模組在被呼叫時才執行。至於 js 於何時下載至使用者端，瀏覽器理應有權衡機制選則適當的時機下載。
欲在TW裡控制下載時機，理論上套件須至少分離為兩個 js，其中之一只做初始化動作，其餘由各套件初始模組處理動態載入（可藉由 xmlhttprequest 載入 js 再使用 eval() 執行之）。內含許多不同功能模組的大型套件或TW 核心，比較適合此方式。至於單一功能（多數TW套件屬此類型）或小型套件，則可能無此需要。
若套件太多或太大以致影響下載速度，也有其他解決方法。例如：
所有套件放進單一個 js 或分類放置不同 js，然後使用 compact 的工具將 js 緊實瘦身。
如果套件是load-on-demand而不是一開始就載入的話，是不是就無法被正確執行呢？
雖然技術上可以克服到一定程度（前面提到其中之一的方式），但是需要套件遵循特定原則，才能發揮效用。
BramChen
此因程式碼與資料一次載入本地端，所有的操作都在記憶體中進行。
但也因此，目前 TW 仍不適合存放大量資料，尤其是安裝大量套件。
從另一個角度來看，動態載入可能造成操作時須「等待」延遲。
至於，應該讓時間花在啟動還是操作時，可能因人、因時、因地而有所差異 ....
BramChen
安裝 InlineJavascriptPlugin ，使用語法： <script src="/pathto/YourJs.js"></script>
（也可配合 PopupTipsPlugin 使用）
js 會在首次執行上述 <script>時，下載 "/pathto/YourJs.js"。至於什麼時候用甚方式執行，可以自由發揮。
--
MilchFlasche
On 3月30日, 下午2時41分, BramChen <bram.c...@gmail.com> wrote:
> 從另一個角度來看，動態載入可能造成操作時須「等待」延遲。
> 至於，應該讓時間花在啟動還是操作時，可能因人、因時、因地而有所差異 ....
>
> Bram Chen
> Website:http://ptw.sf.net/
今天測過，若是一個全新的訪客來到我的ccTiddly主站，由於script通通未被cache，加上資料、主程式，還有連到SiteMeter時該
死的耽擱遲鈍，很可能要花上至少四、五十秒才能載入完，這對時下的使用者來說幾乎是不太可能理解和忍受的。但是外國的TiddlyWiki開發社群，卻
很少人針對長久的載入時間措意或討論，我不禁疑心，是不是因為國外的寬頻服務發達，即使數百KB的資料量對他們來說也不過是彈指間事？是否因此他們渾然
不覺這樣的問題有什麼緊急的？相對來說，以架在ByetHost這種免費而無法要求速度的網路空間上，加上台美之間先天網路連線速度的劣勢（我想難免會
有的吧），就使得造訪用TiddlyWiki架的站這件事一開始就讓人印象不佳。在這種情形下，相信很多人都會寧可把等待的歷程拆解到操作時候的稍微停
頓，而不是一開始載入的曠日廢時吧。
oc
想來對英美玩家而言，下載速度應該也是個困擾。
回到Bram說的「應該讓時間花在啟動還是操作 ....」。也許我們可以想像一個折衷。
例如首頁下載的時候只下載首頁所需的條目和CSS相關條目，這樣首頁大小應該不超過十K，下載完之後，訪客通常也需要一些時間瀏覽版面，才能決定他下一
步要點哪個連結，這個時間我們繼續下載必要的核心程式，例如產生連結的功能等，把工具功能如存檔、備份等，延遲到第三優先才下載。
這樣首頁速度很快，也不會妨礙操作速度。
異想天開，僅供參考。
oc
BramChen
2) 免費空間提供的資源，尤其是伺服端 script 與 db 有一定的限制，我相信有 2/3 ~ 3/4 的延遲，問題源頭不是 TW。從 oc 所舉例的 TiddlyTools 為例，應足以佐證，尤其是 TiddlyTools 提供（執行）為數可觀的 plugins 與scripts，全部下載執行完畢大約 15 秒。
3) 架設網頁時，假設TW文件大小約1M （通常須出現在首頁的資料，可能只有幾KB），藉由修改 PageTemplate 使不顯示 SideBarTabs，能讓「檢視首頁」的速度提昇到可接受範圍內。（我猜這是 Eric 首頁不出現 SideBarTabs 的原因之一。）
4) 雖然適當安排首頁版面後，可能會有不錯的表現。即使如此，相信 Jeremy 也在努力修改提昇這部份的效能，何不給點鼓勵的掌聲。
不知兩位試過這些無須修改程式碼的方式？也許可以建議 Jeremy 將 SideBarTabs 修改成「選擇性顯示」且「預設隱藏」。
--
oc
Bram提到的方法我以前沒看過。列入tip。呵呵。
oc
BramChen
哈哈，Bram不需擔心，我們，好吧，我，我不是抱怨，身為使用者，享受到TW的便利已經夠多，我們只是貪心想要擴大應用層。
事實上，oc 的許多建議，非常專業，也相當有參考價值。
存屬個人的觀點，始終認為以 TW 的設計理念，無須過度擴大可應用的範圍。試想，有天 TW 原生支援的 storeage 為資料庫，資料可「即時存取」如一般 web ap，繁雜而且完整的功能，體積至少是 1~2MB 的核心，如常見的「小型」wiki、blog 或 cms ，需要安裝伺服端的運行環境 ....。
最新的 TW trunk 已可經由套件的相關性，設定載入的先後順序，但是即使如此簡單的需求，核心也須增加近 2、30 行指令，作嚴謹的處理。猶記得 TW 1.2.x 僅約約 160 KB，而即將釋出的 2.2.0 已接近 300KB。如果有一天 TW 十分完美，但臃腫的身軀以 MB 計，我大概會選擇去雲遊四海吧 ....
始終認為，TW 仍應以簡便使用為主，至多扮演「前端」角色。複雜龐大的資料存取，透過類似 TW 2.2 將提供的 adaptor 與後端系統銜接即可。
相信很多問題，應還不至於到非大幅新增或修改核心碼，才能獲得完全解決（事實上我也相信，很多問題在時機成熟之際，往往自然地水到渠成....）。當然，各位也無須因我個人的淺見，對 TW 的「未來」失望。也許哪天醒來，突然發現 TW 神奇的符合各位的殷殷期盼， Jeremy 總是會帶來驚喜 ....
Bram提到的方法我以前沒看過。列入tip。呵呵。
最佳的解決方式，通常也伴隨更多的代價。選擇簡單一點的方式，也許也不是壞主意。
先前提到的方式，實作之前不保證一定適合所有使用特例（也可能因人而異），或保證持續的可行性（經由核心的修改，可以降低影響），但是至少可以試試。 至於 server-side 的延伸版能不能有效發輝，也須實機測試後才能知曉。伺服環境的變因較多，得配合更多「參數」的調整，當然需要更多的耐心測試 ....
MilchFlasche
On 3月31日, 下午3時47分, BramChen <bram.c...@gmail.com> wrote:
> 1) 首先，我並不認為擁有豐富設計經驗的 TW 團隊或套件開發者，漠視這類的聲音，或不知該如何解決這樣的問題。但是一定還正在奉獻他們工作時間外的時間，讓
> TW 滿足不同的需求，除了「限期改善」....
>
我不得不承認，上篇純粹是沒有建設性的抱怨文XD
> 2) 免費空間提供的資源，尤其是伺服端 script 與 db 有一定的限制，我相信有 2/3 ~ 3/4 的延遲，問題源頭不是 TW。從 oc
> 所舉例的 TiddlyTools 為例，應足以佐證，尤其是 TiddlyTools 提供（執行）為數可觀的 plugins
> 與scripts，全部下載執行完畢大約 15 秒。
我很久沒去他的站了，剛剛開TiddlyTools居然花了超過兩分鐘在載入，平均每秒約下載15KB左右，是東森寬頻太慢嗎？@_@
然後載入完以後Firefox數度出現程式碼無回應，最後就卡死在splash screen進不去。我看我的Firefox也有不小的問題XD
太扯了......和Bram哥說的情形還差真多，嗚嗚。
>
> 3) 架設網頁時，假設TW文件大小約1M （通常須出現在首頁的資料，可能只有幾KB），藉由修改 PageTemplate 使不顯示
> SideBarTabs，能讓「檢視首頁」的速度提昇到可接受範圍內。（我猜這是 Eric 首頁不出現 SideBarTabs 的原因之一。）
這應該是個好方法，一定要試試，謝謝！
BramChen
是東森寬頻太慢嗎？@_@
這個問題，以前討論過，我就不在重複了。
然後載入完以後Firefox數度出現程式碼無回應，最後就卡死在splash screen進不去。我看我的Firefox也有不小的問題XD
很有可能，增加一個全新的Fx profile 試試便知。
或必要時，改一下 Fx about:config 的 dom.max_script_run_time 的值 （15 or 20 ....）
這應該是個好方法，一定要試試，謝謝！
MilchFlasche
On 4月1日, 下午9時14分, BramChen <bram.c...@gmail.com> wrote:
> 2007/3/31, oc <blog...@gmail.com>:
>
>
>
> > 哈哈，Bram不需擔心，我們，好吧，我，我不是抱怨，身為使用者，享受到TW的便利已經夠多，我們只是貪心想要擴大應用層。
>
> 事實上，oc 的許多建議，非常專業，也相當有參考價值。
>
> 存屬個人的觀點，始終認為以 TW 的設計理念，無須過度擴大可應用的範圍。試想，有天 TW 原生支援的 storeage
> 為資料庫，資料可「即時存取」如一般 web ap，繁雜而且完整的功能，體積至少是 1~2MB 的核心，如常見的「小型」wiki、blog 或 cms
> ，需要安裝伺服端的運行環境 ....。
我不期待TW本身變這樣，我只期待有這樣的adaptation。
>
> 最新的 TW trunk 已可經由套件的相關性，設定載入的先後順序，但是即使如此簡單的需求，核心也須增加近 2、30 行指令，作嚴謹的處理。猶記得 TW
> 1.2.x 僅約約 160 KB，而即將釋出的 2.2.0 已接近 300KB。如果有一天 TW 十分完美，但臃腫的身軀以 MB
> 計，我大概會選擇去雲遊四海吧 ....
的確。如果光是主程式都要載入很久（我說的是架站的情形），那就算資料已經分離了，問題也還是無法解決。
我想這也是很多未來RIA的困境：Flash也好、其他的解決方案也好，往往都不得不花比過去的純HTML方案更久的時間載入。
>
> 始終認為，TW 仍應以簡便使用為主，至多扮演「前端」角色。複雜龐大的資料存取，透過類似 TW 2.2 將提供的 adaptor 與後端系統銜接即可。
說真的能有這樣我已經願意偷笑了。如果adaptor可以做到，不管後端是什麼，我在TiddlyWiki的前端可以將後端的資料用非同步的方式逐漸、
或是在需要的時候再流進來，而且編輯和修改的結果也可以自動回存到後端的資料庫裡（不用手動按「Sync」。我對手動按「upload」、手動按
「save」、手動按「sync」的方式有說不出的反感，尤其當你想到ZiddlyWiki、ccTiddly早就把自動上傳實做出來之後）的話，這應
該已經是夠讓人寬慰的解決方案。我並不介意後端還要裝MediaWiki還是什麼別的東西才能處理龐雜的資料，但是至少拜託讓TiddlyWiki這麼
棒的前端也可以支援這樣的東西吧。
oc
好吧，我有個異想天開的點子，既然TW的主程式是javascript，有沒有可能做成FireFox的plugin？這樣使用者訪問TW網頁的時候，
完全不用下載TW主程式，只要下載文件條目即可。可能嗎？
或者有沒有可能讓線上TW偵測訪問者是否有個TW已經啟動了，有的話，主程式就不用下載。如果沒有，才全站下載。這樣TW就變成只對TW使用者友善的網
站，對非TW使用者，下載就要花很多時間。
完全沒程式概念者的亂想。
oc
Bram
On 4月2日, 下午2時31分, "oc" <blog...@gmail.com> wrote:
> 繼續在這篇討論有點怪，好像跟主文無關。不過既然討論到了，隨緣也是個好選擇。
還是另起個主題繼續吧：
http://groups.google.com/group/TiddlyWiki-zh/t/6be127884d7c5929