您在這裡

首頁 » Forums » 綜合討論 » 閒話家常討論

麻煩懂程式的人幫我看看手冊裡的 API 項目

ddtet's 的頭像
由 ddtet 在 2007-05-03 (四) 10:04 發表

在還沒看過幾篇原文站文章之前，還有著想要把handbooks中文化的念頭。
不過實際看了幾篇之後，發現其"不可為"的地方。不是說handbooks的內容不好，而是很多部分大部分人用不到。
算是"比較不急"的部分，比如說是怎麼去貢獻模組程式，這個過程是如何去管理。對於大部分使用者連模組都還寫不好的站，似乎並不是急著需要的東西。
個人工作需要要研究怎麼開發模組，查了幾次 api 的文件，常常遇到看了半天不知道這個程式要怎麼用。
看了好一堆上下的原始碼，再試了許多次才能知道一個大概。所以想把研究時遇到的函數或是hook放到手冊中。

麻煩懂程式的人幫我看看我的文章有沒有什麼問題...
不管是排版、語法、語氣或是其它任何可以改進的地方都請告訴我....
或者是覺得這種東西沒有必要出現在本站上，也可以講出來....

希望是在我還沒有po很多篇文章之前，把一些能避免的錯誤改掉，免得浪費太多時間。

真要說心得，或是"原創"的話，也就只有最後的"範例"。在一個翻譯API網站函數的文章裡加上一大堆"心得"很奇怪，而且事後要找也不好找吧！
個人看程式說明的時候，除了格式之外，也常常去看它的範例，有時候那反而比較讓我能知道這個函數怎麼用。
所以一來是翻點原文的函數，一來是加上經過我試驗過的範例。看看最後能不能變成一個函數庫可以讓人來查。

真的要作心得分享的話，那可能得作更詳細的規劃了。而且也不是我這個"學到一半"的人能貢獻出來的東西。
也許等到我"略有小成"之後，也許會試著發表"一系列"的文章.... 現在的我，有些觀念也不知道對還是不對... 就不要發表"心得"去誤人誤已了... XD

我只是一個撰碼員，靠寫程式過活。
自從 Drupal 在 4.7 版的時候知道他的存在，但是後來跳去其它程式語言很久沒回來。
變成 D5 比較熟，D6 知道一點，D7 還在學的狀況…

先求有，再求好也ok啊
可以先在討論區貼一下
大家討論討論，有個定案，再進到手冊裡頭
手冊其實很彈性的

/************************************************
* 你的回饋，讓Drupal越來越茁壯 * Drupal社群越茁壯，你就越有力量 *
************************************************/

--
from open mind to open source~

Drupal的程式架構分層沒有劃分的很清楚
簡單講一下，要真的說到是API，大概是hook_xxx系統比較有像
還有form API的系統，最後是include裡頭的inc
因為那是歷經版本演變時，比較不可能更動的部份
hook_xxx是module導向的
form是依據把陣列當成物件的方式的
include/裡頭的則是function導向的

而某些third party的模組提供的API（location、voteapi）
又跟drupal的方式有些許不同
總結來說，要說drupal的API，其實老實說有點亂
但綜合起來又很好用

而有些核心模組的function，在程式架構時，並沒有把他們當成API
若是API的話，通常會提昇到include裡頭的inc，如user_mail在5.0後就變成drupal_mail
但user_load一直停留在user.module，其實就表示他是可被取代的
實際上，也很少把他當API使用，hook_user比較是user.moudle的API
而user的物件，則都用globle的方式來取得
唯有要hack user系統時，才會去動到user_load這個東西
因此比較算是hacking時用到的function吧

我覺得納格髓的東西不錯，可以在手冊裡「開發、把玩 drupal 指引」裡頭新增section
至於真正API的應用，也可以放在這個架構裡頭～
相當於drupal.org上handbook的for developer

/************************************************
* 你的回饋，讓Drupal越來越茁壯 * Drupal社群越茁壯，你就越有力量 *
************************************************/

--
from open mind to open source~

看到 jimmy 的分析，讓我發現一些我沒注意到的東西。
原文站的 API 讓我覺得"難用"的其中一個原因，是它把hook和函數寫在一起。所以看完簡單的說明和原始檔還是不知道這是在作什麼。如果是hook的話，可能再把每一個參數都講得更詳細一點。
看來把函數從 API 獨立出來是一個比較好作法。移到到「開發、把玩 drupal 指引」感覺是一個不錯的主意，我把它獨立出一個「函數庫」的子項好了(雖然還沒資格稱為「庫」)。
合在一起似乎重轁原文站的覆轍。

看來對於寫作上的問題不是很大，口語化少一點可能會好一些。
這樣的話，那我就可以繼續把其它我知道的函數po出來。當然也希望也有其它人一起來分享。

至於心得的話，可能還要過一段時間吧！一來看的東西還不夠多，二來是最近遇到一個讓我覺得很悶的事情，心情有點受到影響。
我知道我這種"剛入門的人"發表的文章，有時候有特別的價值。因為這種人有時候會把高手早就「變成習慣」的小地方寫出來。

再看看有沒有其它的意見.... 之後就是著手進行 。

我只是一個撰碼員，靠寫程式過活。
自從 Drupal 在 4.7 版的時候知道他的存在，但是後來跳去其它程式語言很久沒回來。
變成 D5 比較熟，D6 知道一點，D7 還在學的狀況…

我已經把位置移動過了，移到「開發、把玩 drupal 指引」下的「函數庫」。
另外把之前發表的兩篇內容作了一些修改，把範例的部分移到前面，程式碼則被我丟到最後面。
老實說，包括我在看說明的時候，只想知道要怎麼用，懶得去管SourceCode長什麼樣子。所以我翻譯的時候也沒有去作原始碼註解的翻譯。
今天晚上開始再繼續分享其它我知道的函數...

我只是一個撰碼員，靠寫程式過活。
自從 Drupal 在 4.7 版的時候知道他的存在，但是後來跳去其它程式語言很久沒回來。
變成 D5 比較熟，D6 知道一點，D7 還在學的狀況…

附議!!

搞講清楚 hook 是在什麼時候被呼叫的，在開發模組的時候是必要的。
尤其是這種類似事件處理的機制，有時候哪個 hook 先被處理到就關係到最後的結果。
所以知道 hook 要怎麼用，對於開發上會有很大的幫助。

不過研究 hook 的難度就更高了，往往一個 hook 就要參考數個不同地方的程式碼，還得要了解該模組是怎麼運作的。
就我目前的功力還沒辦法弄得很清楚，也許要靠其它有研究的人來分享了。

看看誰要認養它，"主持" hook 這個區塊囉~~

我只是一個撰碼員，靠寫程式過活。
自從 Drupal 在 4.7 版的時候知道他的存在，但是後來跳去其它程式語言很久沒回來。
變成 D5 比較熟，D6 知道一點，D7 還在學的狀況…

我覺得寫hook的難度不在於寫 "hook那時被呼叫"
而在於具體地寫出 "應該, 可以在hook 裡做什麼"
因為對於不同功能的模組, 同一個hook 可能要做完全不同的東西
要具體地寫出來可能會有困難
始終要試一下才會明白

我在我的blog 都寫過一篇 form API, hook_submit, hook_validate 的文章
但自己寫完都不覺得會對初學者有大幫助
正在試用flash 的形式說明
可能會好一點

Joetsui's blog