jQuery 處理 json 內容

這已經不是第一次了,浪費了我整整半小時,就是在找出原因。。。

這次,寫下來提醒自己:


 

jQuery 中,進行 source 呼叫時的規則:

  1. 呼叫時,查詢關鍵字是以URL String的形態傳送到服務端。
  2. 服務端返回時,直接以 echo json($array) 返回字串即可。
  3. jQuery會自動解讀 json 內容,以指定的形態進行後續處理。

 

。。。

這次犯這個老錯誤,可以說太久沒弄程式了,還在熱身狀態中,無法避免犯這類錯誤。但如果下來再犯同一個錯誤。。。

可以買塊豆腐敲頭去了~

CodeIgniter (1) — 經濟不景氣,正是修行時

近幾個月來,如果有關心經濟的朋友,肯定會被嚇到目瞪口呆。雖説整個大環境都如此,大部分地區都進入經濟低迷的情況,但以馬來西亞這個充滿天然資源、基本面穩定的國度,竟然會進入如此窘境,說穿了就是上面的那隻雞沒能力,希望早日超度了,國家重新邁入正途。。。

啊~又嘮叨了。。。

嗯,正如主題說的,這個時節正是修行的好時候,當然別開著面書,你將會冒著爆血管、心臟病的風險。。。

嗯,就開始第一篇記錄我的 CodeIgniter 修行日記!

CI-Mainpage

Continue reading “CodeIgniter (1) — 經濟不景氣,正是修行時”

jquery.min.map — 再一次被Google Chrome玩死。。。

這是一個悲慘的實錄。

一早就被告知某個正在開發中的網頁程序出現不知名問題。最頭疼的是這網頁主要以jQuery開發,要檢查一些所謂不知名的問題時,可以說是老鼠拉龜無從下手。這次的情況就是如此。

在進入用戶界面後,一旦刷新頁面就會跳出一個警告通知,裡面只有非常精簡的一個英文字:error。花了兩個人,一個早上做檢查,也查問了谷歌大神不知道多少次數了,還是找不到問題的源頭在哪。

最後我只好先放下,讓同事繼續尋找根源。結果剛才去喝了一杯咖啡,回來就立刻有了靈感!我在想:頁面上的動作是通過jQuery和php互動,然後把返回的結果重新整理了,再顯示在頁面上。那麼有沒有可能在網服上的error log中找到答案呢?

結果真的讓我看到一絲曙光了。。。

httpd error log

真的詭異。jQuery 明明只用了一個主要的 min.js,怎麼會無端端跑了這個未曾謀面的 jquery.min.map 出來?!再次不恥下問去麻煩了下谷歌大神,才得知原來一切都是Google Chrome更新後搞出來的問題!

在剛更新的32版中,它預設自行開啟了 Enable source maps的選項,所以每當其進行jQuery的查詢時,會自動要求查詢 jquery.min.map 這個文件。由於在 jQuery 源碼中,這個檔案屬於可選項目,所以導致找不到檔案!

從 羊小咩-喇低賽 處的解釋是:

what is jquery source map

解決方式有二:
1. 修改Google Chrome的設置。進入【Developer Tools】 -> 【設定】,把 Enable source maps 這個項目關掉(false)。

2. 下載同一版本的source maps,放置在網服上的同一位置。

。。。。。

最後,Google Chrome貌似不時的更新就會給我們一些特別驚喜。。。
這些驚喜是不是可以盡量減少啊? (握拳熱淚)

CakePHP學習手札 — Auth,用戶登錄管理

在開發過程中,都是使用其提供的手冊來進行學習。在CakePHP組中,他們稱之為Cook Book。第一章的實作例子就是一個簡單的部落系統,由於整個過程中都非常順利,所以我就不在這手札中提了。這裡要提的,是接下來實作演習中的用戶登錄管理作業。

先來個短短的說明:

Auth是其內建的機制,提供了三種登錄管理:Form, Basic, 和 Digest。在這裡,我使用的是最普遍使用的Form機制。簡單說就是進入一個登錄網頁,輸入你的用戶名、密碼等重要訊息,系統檢查過後就會給予其戶口關聯的使用權力。

CakePHP Cook Book中,介紹了非常直觀使用的 users/login 和 users/logout 這兩個例子。如果按照它的方法,在進入需要權力的頁面時,系統就會自動把你帶到 users/login 這個頁面,讓你進行登錄動作。退出時也只需要進入 users/logout 這個位置即可。非常簡單明確。

在學習過程中,發現一個很奇怪的情況:一旦抵達某個步驟後,就會突然間不管用什麼方法進入 users/logout 這個鏈接頁面,也不會有任何反應。儘管我從頭檢查了全部代碼和例子,都找不到真正的問題所在。結果重做了三次,最後才給我找到了答案。

管制可瀏覽頁面
登錄管理機制本身提供了一個非常簡單的頁面控制方式。只需在當前需要進行登錄限制的Controller項目中,加入下面的代碼,系統就會在某人進入這項目的頁面時,自動使用 isAuthorized( ) 功能來檢查其權限。

public function beforeFilter() {
    parent::beforeFilter();
    $this->Auth->allow(‘index’,’view’);
}

上面的例子中,不管是誰進入這個項目中的 /index 或者 /view 都沒問題。但如果進入其餘的頁面,例如 /add 就需要登錄才可以繼續瀏覽。如果項目中只有一個或少許頁面需要管制,可以把上面的例子改成限制登錄人員才能瀏覽 /admin:

public function beforeFilter() {
    parent::beforeFilter();
    $this->Auth->deny(‘admin’);
} 

登錄用戶權限管理
上面的例子只能針對是否能登錄才能瀏覽某個頁面。有時候我們需要多個用戶層次,來進行訊息管理動作。以論壇作為例子,論壇中基本用戶就分成三大類:版主、會員、遊客。其中會員和版主所擁有的權力是不一樣的,前者只能夠進行貼文、回應等動作,而版主則擁有更大的權力來管理論壇。

在CakePHP中,用戶權限層次管理也非常容易,下面例子為只有管理員可以進入用戶管理、文章刪除頁面 :

public function isAuthorized($user){
// Set default admin’s access rights
if(isset($user[‘role’]) && $user[‘role’]===’admin’) {
if(in_array($this->action,array(‘users’,’p.delete’))){
return true;
}
}

}

上面兩個管理工具,基本上配合得好的話會讓編程時,減少很多不必要的力氣來編輯這種常用的用戶管理機制。真的可以節省非常多的時間啊~

我所面對的問題
文章開頭就說到了,我在這個部份面對了一個很詭異的登錄、退出問題,一直檢查到最後才發現原來我犯的只是一個小小的邏輯性錯誤。在頁面權限管理機制中,我沒有放入 /login 和 /logout 這兩個頁面的使用權限,當只是用這一個機制,其實不會面對什麼問題的。但後面我把用戶權限管理機制加入後,由於其中沒有說明這些已經登錄的用戶可以進入 login 和 logout 頁面,所以在進入時就直接被轉移到之前的頁面,而造成不能運作的假象!

最後我在 AppController 中加入這兩個頁面的進入允許後,卡了我三天的登錄問題就這樣解決了。。。

為何把代碼加入AppController,而不是相關項目的Controller中?
任何東西加入AppController將會直接在整個系統框架中實現。既然 login 和 logout 都是公用的功能頁面,直接加入 AppController 就好了。否則就需要每個Controller項目中都需要加一個。

暫時就到此為止。繼續 coding 去~!

CakePHP學習手札 — 前言

目前由於增加了新項目,在分發了工程後開發部人手不足,逼不得已把一些開發項目抓回來自己弄(其實自己也是蠻想做的啦~)。為了讓接下來的開發過程稍微輕鬆,所以決定用一個基於PHP使用的MVC框架來做這些項目。而CakePHP就是我從芸芸眾網中挑選出來的其中一個“看起來比較沒那麼難學,但擴展能力足以使用”的框架。

MVC框架(Framework)其實說簡單的就是它把開發時所需要的一些常用項目都幫我們弄好了,開發者需要的也只是配合這個MVC的開發模式進行編程設計工作。

M代表Model(模型),負責和後部資料庫連接的工作。
V代表View(視圖),負責所有與用戶互動的部份,或者也可以看成是用戶頁面。
C代表Controller(控制器),負責項目中的流程部份、處理事件以及進行回應。

有興趣的朋友可以去看看Wikipidia中的說明。

下來我將會不定期,把自己在學習CakePHP的過程中,所遇到的問題以及心得一一記錄下來。朋友們如果想要一起研究的,也可以在這系列中回應,我們一起學習。:)