跳到主要內容

文章

jQuery event.namespace

最近才發現 jQuery event.namespace 可以讓你只移除自己註冊的 event listener 而不移除其他人註冊的。 往常我們多半指定 event type 來註冊: $ ( document ) . bind ( 'mouseup' , myListener ) ; 並指定同一個 event type 來移除: $ ( document ) . unbind ( 'mouseup' ) ; 但有時候你使用別人的 widget 或 library 也許它也註冊了同樣事件的 listener,或是你不確定有沒有,為了避免不小心 unbind 其他人的 listener,我可以在註冊加上 namespace 如: $ ( document ) . bind ( 'mouseup.line' , myListener ) ; .line 就是自訂的命名空間。 然後可以移除該 namespace 的所有 listener: $ ( document ) . unbind ( '.line' ) ; 這時如果 document 上也有別人註冊的 mouseup 就不會被你呼叫的 unbind() 移除。
最近的文章

margin collapse 造成垂直捲動條

有次我發現即使我將 html, body 都設定沒有 margin 如: html { height : 100% ; margin : 0 px ; } body { height : 100% ; margin : 0 px ; } 但頁面仍然產生垂直捲動條(scrollbar),檢查後發現 body 跟 text1 的上白邊合併,造成 body 向下移動,因為 body、html 高度相同,下移就造成右方垂直捲動條出現。 另一個例子:text1 的下白邊與 text2 的上白邊合併 (collapse) 這頁範例 可以重現以上問題。 這不是 bug,而是規格上定義的 margin collapse : 8 Box model / 8.3.1 Collapsing margins 解法  < h1 style =" display : inline-block " > text 1 </ h1 > < h1 style =" margin-top : 0 " > text 1 </ h1 >

ZK 與響應式網頁設計(RWD)

響應式網頁設計 (RWD) 就現今而言應該是許多網站必備的條件之一,ZK 框架可以幫你從一個抽象層次較高的角度滿足 RWD,不需要了解 CSS Media Query 的細節。 元件層級 元件層級的 RWD 是由元件內部自動完成的。每個 ZK 元件都能區分瀏覽器的種類,因此會自動依據桌上型或行動裝置瀏覽器來自動調整元件的外觀,不需開發者介入,例如 datebox 在桌面瀏覽器會跳出小月曆: 在手機瀏覽器就會自動變成下方滾動條: 頁面層級 頁面層級的 RWD 因為牽涉到版面設計,因此無法靠元件自動完成,因為畢竟每個頁面需要的版面設計皆不相同,這通常不是一個技術性的決定,而是政策性或設計性上的決定,因此 ZK 提供一些工具讓你實現 RWD。以下根據你想要達成的效果,概述你可用的工具。 寬度、版面自動調整 如果你想要做出的效果是,畫面內各區域自動調整寬度,較窄時調整位置,我非常推薦搭配 Bootstrap Grid 與 ZK 一同使用,因為 易於整合 。使用 Grid system 只要在 div 套上 CSS class,如 col-md-4 ,因此跟 ZK 整合很容易,不需要特別的設定與程式。 元件變換 如果你希望畫面寬、窄時,各用不同的元件來顯示,例如側邊欄在畫面變窄時消失並換成小的選單圖示,這時元件本身當然無法得知要做這樣的轉換,你可以透過 onClientInfo 事件 或 @MatchMedia 來偵測畫面寬度變化,並針對該變化調整畫面元件。 更多細節可以參考以下資源: Use Bootstrap with ZK: Responsive Admin Template 範例專案 線上展示

innerHTML 的安全風險

問題 若你要實作一個使用者輸入的功能,並把輸入的內容顯示在網頁上時,應避免把使用者輸入的值直接指定給某個 element 的 innerHTML 。因為若是使用者輸入包含 HTML、JavaScript, innerHTML 就會解析並執行: var userInput = '<img src="javascript:alert("XSS")">' element . innerHTML = userInput ; 因此可能 user A 的惡意輸入,會被系統顯示到 user B 的畫面上,進而執行特定成程式碼而造成 XSS 攻擊 。 解法 一般會先想到 encode HTML,但是如果只是要顯示文字,將使用者輸入值指定給 textContent 會更簡單,無需 encode,該值會被當成純文字處理,並不會執行 javascript。 var userInput = '<img src="javascript:alert("XSS")">' element . textContent = userInput ;

Mac 藍芽無法使用問題 (not available)

最近開始用藍芽,發現 Mac 一旦休眠之後藍芽就會不能使用,變成關閉狀態: 或是顯示 Bluetooth Not Available 即使到設定畫面, 啟動藍芽(turn bluetooth on) 的按鈕也是 disabled 無法點。 必須要 重開機 網路上有提到 許多解法 ,但比較少提到的是如果你曾安裝 Android File Transfer 就會有此問題,解決方法只有移除一途,我就遇到這個情形,已驗證過,的確可以解決。 這篇文章有提到 。

避免落入預期解法的死胡同

買錯票 某天我要去台北,卻發現自己前一天起迄站買反,買成 台北 —> 台南 ,但是搭車前才發現,詢問服務台人員,只得到回覆說發車前 30 分之前才能退票,自己也依稀記得規定是如此,因此只好認栽,誰叫自己買票沒看清楚,趕緊自己去重買一張到台北的車票。後來老婆提醒我也許可以換票,再至服務台詢問,服務小姐說若是錯過班車,可以當天的票搭乘較晚班次的自由座,但是我給她看我的票是早上出發,卻要搭晚上的車,我就解釋是因為我買錯票,她猶豫了一下,竟然說了一個聽起來可以幫我換票的說詞(我忘了他確切的用詞),我雖然感到驚訝但是我已經買了到台北的票,只能說來不及了,她就建議我仍然採用換搭自由座的方法。 預期解法 - 退票 這件事我也犯了一個跟某些客戶常犯的錯誤,就是「沒有提供背景資訊」,或說「 預期解法 」。我心理預期我的問題的解法只有「 退票 」,因此我只問了特定的「退票」事宜,發現不能用「退票」解決,就以為沒有解法了。如果我能第一時間提供比較完整的背景資訊(也就是買錯票的狀況)給服務台,因為服務小姐擁有較完整的解決方案,她可以從我的背景資訊中,更清楚我的需求,進而幫我想到其他解法。 破除方法 - 主動探詢 當然服務是雙方的,如果服務台小姐可以在我第一次詢問時,就更主動探詢更多的背景資訊,她也就有機會促使我講出原本的問題,並從中找出其他解法,最終就提供了一個更好的服務體驗。 回到原始問題 在 ZK 技術支援上,有時客戶問到一個特定的功能可否做到某個效果,問題很簡短,也沒有交代需求或應用情境。如果該功能確實可以達到該效果,我通常會簡短肯定回覆,只是確認或補充說明。如果無法做到,或是該功能跟客戶預期的效果沒有什麼關聯,我會在信末提說:「 如果你能告訴我們你的應用情境,也許我們能找到其他解法 」。因為我推測這位客戶已經落入「預期解法」的思維,他已經認定這個特定的功能就是解法,如果不能做到他的要求,就是不能解。我問的那句話就會 促使客戶描述原本的應用情境 ,我可以據此去找到另外的替代方案或更好的解法。

專業的提問

Photo by rawpixel.com from Pexels 客戶未提供必要資訊 某天去了一家從未去過的麵店,因為趕時間看一眼菜單就點「 乾麵加蛋 」,付款時發現店員可能聽成「 麵加蛋 」,因此做成「 外帶、肉羹麵加蛋 」。我的確是忘了說我要「內用」,店員如果只聽到我點「麵」,而店裡提供兩種麵,要避免做錯,他應該要問我: 肉羹麵還是乾麵? 外帶還是內用? 其實客戶未提供必要資訊是可以理解的。 提問是種專業 技術支援上經常遇到這種情形,客戶通常不會提供他所遇到的問題的完整或必要的資訊,甚至只會說「頁面不會動」這種很籠統的描述。因此我們要根據每個不同案件,來提出必要的問題。有人也許會擔心問客戶問題會不會讓人覺得不專業,好像我們應該要能直接吿知答案。但冷靜想想,不管是誰都無法在缺乏必要資訊的情況下找出問題所在或提供精準的服務。其實遇到問題的客戶是擁有完整資訊、最接近問題的人,畢竟問題就發生在他眼前,只是他不知道哪些資訊能解決問題。而我們提問代表著我們對問題狀況的熟悉與專業,知道需要哪些資訊來解決問題,因此良好的提問能夠有以下效果: 引出關鍵資訊 釐清描述不清的現象 確認彼此認知是否一致 因此能夠問對問題也是一種專業。