某人的網站近日發佈 zen-cart 與 xt:Commerce 兩者比較的議題，
有比較才有進步，這當然是件好事。
剛好 zen-cart 近期釋出了 v1371 utf-8版本，就安裝來試用看看，
初用心得如下：
正評：
1. 安裝程序很明確好用。4顆星
2. 後台執行簡潔快速。3顆星
3. 與 PHPBB 整合。 3顆星
4. 商品屬性功能完備。 4顆星
5. 區塊管理調度功能完備。 4顆星
6. 商品價格屬性快速編輯。 4顆星
7. 數位商品下載管理功能尚可。 2顆星
8. 報表統計、批次列印功能。 3顆星
負評：
1. 後台版面為求程式簡潔，反造成介面簡陋、散亂
2. 預設前台樣版質感粗糙
3. 應屬在同一畫面管理的功能卻分散各處，不夠直覺
總評：
zen-cart 的許多項目的功能獨到，
部份功能是 xt:Commerce 尚未作到的，
可惜各功能無法在操作介面上作有效的佈局統合，
佈局過於雜亂可能會造成入門者學習、記憶上的困惑。
總體來說，以 Open Source 的角度來看 zen-cart ，
它的功能雖算完備，但設計思維仍不夠細膩，
無法讓一般的User第一次操作就接受，這是最大的遺憾。
註：xt:Commerce 3.1的新架構，個人認為最強大的賣點在於
外掛功能的管理及商城機制，但這2個功能的議題要能發酵恐怕
還需要更多的推廣努力，才能讓大家了解它到底有多強。
2008年7月30日 星期三
解決 jQuery 與 TinyMCE 不合的處置方式
大致作好了 attributeManager 的主功能，老大初步測試也OK了，將它加入SVN。
過了2天，老大將原本內嵌在 xt:Commerce 的 FCK_Editor (Web-browser WYSIWYG)，置換成TinyMCE，災難開始...
整 個 attributeManager 開始不靈光了，只要作第2次的 action 網頁就會 redirect 並且當掉(group price 也用了 pquery，它的狀況亦同)，一開始還以為我加入到 SVN 的程序有那些檔案沒作好，接著再懷疑這期間 SVN 的 update 是不是有那裡是影響的關鍵，接著再追蹤 jQuery 的版本與 pquery 的相容度，接著比對各 js 的排列順序,，就這樣搞了快一周...，老大等到快不耐煩了，我的耐性及自信也快被磨到沒了...
在不得已之下，只好作阿呆地毯式偵錯法，將整個 categories.php 的相關連的檔案全部翻過來一遍，刪掉任何懷疑的程式段落，refresh 網頁，不斷的重覆執行會出錯的動作...
莫 非定律始終在你我的生活中，昨天大姊快臨盆了，因為姊夫要執勤，call father 幫她搬東西到新房子去要安靜的準備坐月子，就是這麼剛好，當天就生了...，而這個 TinyMCE 我一開始也曾想過倒底是不是它，但又心念一改，認為它算是很穩定的套件，又是老大放上去的，絕對沒問題，事實就變成絕對是這裡出問題。
立即向老大報告之後，同時搜尋了相關的資料，找到了以下2筆，但經測試仍是不行->
1.http://www.nofluffjuststuff.com/blog/brian_pontarelli/2007/09/how_to_get_jquery_and_tinymce_to_work.html
2.http://dev.jquery.com/wiki/Plugins/tinyMCE
老大果然是老大，他提到 wordpress 也是 jQuery + tinyMCE ，他們就沒有問題？
這 一句話如夢初醒，立即挖開 wordpress 來看，同時再看 Drupal 對於 jQuery 的支援，不看還好，一看...，原來他們都只將 jQuery 當作UI效果使用而已，我竟然取用了版本還沒穩定的 pquery (有人批評它很爛，但反我覺得它很讚，可惜還沒領悟而已)，呼救google大神也沒用...
靈感果然常來自於眼睛閉起來冥想的瞬間，正準備明天再戰，上了床不到10分鐘突然某一段曾解決另一個問題的程式碼如現正流行的 「Tag雲」飄了上來，對哦!問題就在這裡!!
原因及解決：
1. 因為 tinyMCE 是使用 Prototype ， 先天上與 jQuery 不合是必然的，所以必須使用 jQuery.noConflict(); 避免兩者的碰撞。
2. 因為我大量的使用 pquery 的 remote_function()，卻忽略了其產生重覆呼叫的問題(幸好有Firebug加持，才那麼容易發現重覆呼叫)，所以使用了 if(!$_GET['...'] ) 讓 tinyMCE.init() 避免因為 remote_function 而重覆呼叫。
希望這篇碎碎念的文章可以幫得上後來會接觸到這領域的朋友^^
過了2天，老大將原本內嵌在 xt:Commerce 的 FCK_Editor (Web-browser WYSIWYG)，置換成TinyMCE，災難開始...
整 個 attributeManager 開始不靈光了，只要作第2次的 action 網頁就會 redirect 並且當掉(group price 也用了 pquery，它的狀況亦同)，一開始還以為我加入到 SVN 的程序有那些檔案沒作好，接著再懷疑這期間 SVN 的 update 是不是有那裡是影響的關鍵，接著再追蹤 jQuery 的版本與 pquery 的相容度，接著比對各 js 的排列順序,，就這樣搞了快一周...，老大等到快不耐煩了，我的耐性及自信也快被磨到沒了...
在不得已之下，只好作阿呆地毯式偵錯法，將整個 categories.php 的相關連的檔案全部翻過來一遍，刪掉任何懷疑的程式段落，refresh 網頁，不斷的重覆執行會出錯的動作...
莫 非定律始終在你我的生活中，昨天大姊快臨盆了，因為姊夫要執勤，call father 幫她搬東西到新房子去要安靜的準備坐月子，就是這麼剛好，當天就生了...，而這個 TinyMCE 我一開始也曾想過倒底是不是它，但又心念一改，認為它算是很穩定的套件，又是老大放上去的，絕對沒問題，事實就變成絕對是這裡出問題。
立即向老大報告之後，同時搜尋了相關的資料，找到了以下2筆，但經測試仍是不行->
1.http://www.nofluffjuststuff.com/blog/brian_pontarelli/2007/09/how_to_get_jquery_and_tinymce_to_work.html
2.http://dev.jquery.com/wiki/Plugins/tinyMCE
老大果然是老大，他提到 wordpress 也是 jQuery + tinyMCE ，他們就沒有問題？
這 一句話如夢初醒，立即挖開 wordpress 來看，同時再看 Drupal 對於 jQuery 的支援，不看還好，一看...，原來他們都只將 jQuery 當作UI效果使用而已，我竟然取用了版本還沒穩定的 pquery (有人批評它很爛，但反我覺得它很讚，可惜還沒領悟而已)，呼救google大神也沒用...
靈感果然常來自於眼睛閉起來冥想的瞬間，正準備明天再戰，上了床不到10分鐘突然某一段曾解決另一個問題的程式碼如現正流行的 「Tag雲」飄了上來，對哦!問題就在這裡!!
原因及解決：
1. 因為 tinyMCE 是使用 Prototype ， 先天上與 jQuery 不合是必然的，所以必須使用 jQuery.noConflict(); 避免兩者的碰撞。
2. 因為我大量的使用 pquery 的 remote_function()，卻忽略了其產生重覆呼叫的問題(幸好有Firebug加持，才那麼容易發現重覆呼叫)，所以使用了 if(!$_GET['...'] ) 讓 tinyMCE.init() 避免因為 remote_function 而重覆呼叫。
希望這篇碎碎念的文章可以幫得上後來會接觸到這領域的朋友^^
取消-資料庫錯誤時程式中止
xt:Commerce 加入了 /inc/xtc_db_error.inc.php ，所以當資料庫讀取錯誤時，會整個die 掉，為了在開發過程中可以知道是錯在那裡，所以暫時將它註解掉：
// die($logHandler->displayErrorPage());
// die($logHandler->displayErrorPage());
格子市集與 xt:Commerce 的商城機制
今天很偶然的在黑米 看到這篇部落格文章：打破傳統!幾百元就可租到一個在鬧區合法的店面。
這讓我聯想到前陣子很流行並討論的網格運算，接著又聯想到程式共同開發所使用的SVN概念，它們的概念不管是化整為零或是化零為整，都在相異之中有共同之處，就是眾人合作及集權式管理。
這一周，xt:Commerce 加入了multishop (我將它翻譯成商城) 機制，它的目標就是可以只架一個xt:Commerce 平台就可以設定管理數十個至數百個不同網域名稱的子商店，這麼作的好處有太多了，一時之間也說不完，我就舉個例子好了。
例 如：逢甲夜市商圈中有數百家攤商，每家所販賣的商品只有數樣至數十樣，如果某個攤商自己要作網站介紹並販售自己的商品，在收益與成本的考量下幾乎是不可 行，但是如果有某一家網路顧問公司使用了 xt:Commerce 商城機制，他可以在獲得逢甲商圈中攤商的授權後，為攤商們管理並行銷商品。
大家一定會說，這就是 pchome 的商店街嘛! 沒錯!但最大差別有2處：
1. 店家擁有自己獨立的網域名稱
2. Pchome的開店門檻相較於 xt:Commerce 來得太高
不只這樣，每家商店都可以有自己的：
1.獨立的外觀佈景
2.獨立的運送
3.獨立的金流
4.獨立的訂單郵件發送
5.獨立的google analytics追蹤機制
...
網路管理顧問公司只要收取管理費及共同廣告行銷成本即可，所以就不會有過去要經營商城機制最難以克服的金流、拆帳...等問題，又數十至百家的商店都統統集中在同一個系統中，其中管理程序的簡化就不知省了多少的成本。
以下是 xt:Commerce 商城機制的功能截圖：
以上，就又聯想到另一個商機，只要加上訂位機制就可以是聯合民宿、motel、餐廳的商城系統了，當然這要先等 multishop 開發完成及穩定後再說了。
這讓我聯想到前陣子很流行並討論的網格運算，接著又聯想到程式共同開發所使用的SVN概念，它們的概念不管是化整為零或是化零為整，都在相異之中有共同之處，就是眾人合作及集權式管理。
這一周，xt:Commerce 加入了multishop (我將它翻譯成商城) 機制，它的目標就是可以只架一個xt:Commerce 平台就可以設定管理數十個至數百個不同網域名稱的子商店，這麼作的好處有太多了，一時之間也說不完，我就舉個例子好了。
例 如：逢甲夜市商圈中有數百家攤商，每家所販賣的商品只有數樣至數十樣，如果某個攤商自己要作網站介紹並販售自己的商品，在收益與成本的考量下幾乎是不可 行，但是如果有某一家網路顧問公司使用了 xt:Commerce 商城機制，他可以在獲得逢甲商圈中攤商的授權後，為攤商們管理並行銷商品。
大家一定會說，這就是 pchome 的商店街嘛! 沒錯!但最大差別有2處：
1. 店家擁有自己獨立的網域名稱
2. Pchome的開店門檻相較於 xt:Commerce 來得太高
不只這樣，每家商店都可以有自己的：
1.獨立的外觀佈景
2.獨立的運送
3.獨立的金流
4.獨立的訂單郵件發送
5.獨立的google analytics追蹤機制
...
網路管理顧問公司只要收取管理費及共同廣告行銷成本即可，所以就不會有過去要經營商城機制最難以克服的金流、拆帳...等問題，又數十至百家的商店都統統集中在同一個系統中，其中管理程序的簡化就不知省了多少的成本。
以下是 xt:Commerce 商城機制的功能截圖：
以上，就又聯想到另一個商機，只要加上訂位機制就可以是聯合民宿、motel、餐廳的商城系統了，當然這要先等 multishop 開發完成及穩定後再說了。
datePicker 彈出式日曆調校細節
原本是使用 jquery-calendar，但老大說它是CC授權，為避免爭端不予採用
只好改用 GPL 授權的 datePicker
嵌入方式如：jQuery datePicker
再將上架日期的class 改為 date-pick
echo xtc_draw_input_field('products_date_available', $pInfo->products_date_available ,'size="10" class="date-pick"'); 修改日期格式：date.js
Date.format = 'yyyy-mm-dd';
修改日曆外觀：
datePicker.css
xt:Commerce 外掛功能發想
下列的構想純粹是針對 xt:Commerce 3.1 的新功能：外掛管理的功能發想~
一、功能擴充管理：(這個構念參考自Joomla)
1. 異種平台連接：forum, blog, crm, erp, 會計系統等橋接器管理功能
2. 大型元件管理：
3. 功能模組管理：
3. 自動化程式管理：
二、拍賣競標元件：
三、物流進度查詢模組：
四、紅利積點模組：
五、預約訂房訂位元件：
六、商品追蹤比價模組：
七、團購商品模組：
八、滿額贈品模組：
九、維修管理元件：
十、調查投票模組：
十一、多店商城管理元件：
十二、google sitemap xml 輸出自動化程式：
十三、線上影音播放下載儲值扣點元件：
十五、商品價格快速更新模組：
十六、搭配行銷模組：
十七、flex remoting 通訊橋接：
十八、商店與拍賣同步上下架模組：
1. yahoo 拍賣
2. ebay
3. 露天
4. 樂天
十九、自訂輸出報表格式及微調：
一、功能擴充管理：(這個構念參考自Joomla)
1. 異種平台連接：forum, blog, crm, erp, 會計系統等橋接器管理功能
2. 大型元件管理：
3. 功能模組管理：
3. 自動化程式管理：
二、拍賣競標元件：
三、物流進度查詢模組：
四、紅利積點模組：
五、預約訂房訂位元件：
六、商品追蹤比價模組：
七、團購商品模組：
八、滿額贈品模組：
九、維修管理元件：
十、調查投票模組：
十一、多店商城管理元件：
十二、google sitemap xml 輸出自動化程式：
十三、線上影音播放下載儲值扣點元件：
十五、商品價格快速更新模組：
十六、搭配行銷模組：
十七、flex remoting 通訊橋接：
十八、商店與拍賣同步上下架模組：
1. yahoo 拍賣
2. ebay
3. 露天
4. 樂天
十九、自訂輸出報表格式及微調：
詐騙電話的啟示
相信住在台灣，沒有幾個人沒接過詐騙電話
一般的詐騙電話很容易識破
但這次詐騙的內容讓我嚇了一跳
因為過年前在Yahoo拍賣買了2本書(期貨賽局上下)
我是用ATM轉帳付款的
詐騙電話的那端明確的指出，我的姓名、買了那本書、付款方式
當然電話、及地址他們一定也掌握了。
詐騙的內容是說，我的付款方式選錯，變成分期付款扣繳
(欺負我不懂金流嗎？這種詐騙手法真的很不入流)
(可是我相信仍有很多的人會被這不入流的詐騙手法所騙)
我已經明確告訴他，我知道他是詐騙集團
最末對方仍硬撐威脅說：如果你不相信我的話，
到時候你的帳戶被扣款不要說我沒告知...
這真的很令人發火，對方的口音是台灣人，這和過去的詐騙電話不一樣
而且從說話的方式可以得知，對方的教育程度有達一定的水準
不像是一般的詐騙電話都用套招的，素質低落
剛剛發mail提醒那位賣家(他也回覆已在網站上公告小心遭詐騙的訊息)
但這樣就夠了嗎？
下一步的法律措施呢？
他還要繼續用同一個帳號營運嗎？
他的電腦中是不是仍有一堆的木馬？
或者他使用了某些分享軟體，像Foxy？
對於從事商業交易的電腦可以如此輕忽大意嗎？
該賣家是擁有2顆鑽石級的超級賣家
恐怕他是樹大招風+mail帳號被入侵
所以所有的資料都外洩了!!
這位賣家仍是沒有給我滿意的答覆
但也實在是無法要求對方太多
或許對方也正在為這樣的問題困擾著
或許對方的能力不足
從這個事件可以見到~
拍賣機制的賣家不是每一位都能安全的把關買家的資料
或許他們正是利用拍賣來作為釣買家資料的一個手段
買家的資料從他們的手上被洩露，他們的主張大多是-我也是受害者!
那買家如果真的因此受騙，難道賣家一點責任都沒有嗎？
這恐怕會成為拍賣機制的罩門
因為特定賣家的資訊保安能力不足，導致買家對其的不信任感
進而不消費
如此類似的事件繼續擴展，那消費者便不敢多冒風險
而轉向有公司體制營運的網路購物平台
當然最近許多大型的電視、網路購物平台資料外洩多有所聞
至少消費者可以提出損害賠償
但對於拍賣的賣家，卻很難著力提出同樣的要求
這將是兩者之間很明確的分水嶺
而拍賣平台的供應者，也應該正視這樣的問題
尋求一個更安全有保障的機制
不能說這件事不關他的事
因為他所供應的平台，先天上~
買賣雙方不是每個人都有足夠的資訊保安能力
所以拍賣平台的供應者應該担負起這樣的責任
提供讓人更安心有保障的交易環境
如果沒有，相信一旦話題發酵
許多重視個人資料隱私的消費者
會轉換消費習慣
當然，以私心來說，個人樂見這樣的情事發生
但以公眾的利益來說，這絕對不是一件好事
一般的詐騙電話很容易識破
但這次詐騙的內容讓我嚇了一跳
因為過年前在Yahoo拍賣買了2本書(期貨賽局上下)
我是用ATM轉帳付款的
詐騙電話的那端明確的指出，我的姓名、買了那本書、付款方式
當然電話、及地址他們一定也掌握了。
詐騙的內容是說，我的付款方式選錯，變成分期付款扣繳
(欺負我不懂金流嗎？這種詐騙手法真的很不入流)
(可是我相信仍有很多的人會被這不入流的詐騙手法所騙)
我已經明確告訴他，我知道他是詐騙集團
最末對方仍硬撐威脅說：如果你不相信我的話，
到時候你的帳戶被扣款不要說我沒告知...
這真的很令人發火，對方的口音是台灣人，這和過去的詐騙電話不一樣
而且從說話的方式可以得知，對方的教育程度有達一定的水準
不像是一般的詐騙電話都用套招的，素質低落
剛剛發mail提醒那位賣家(他也回覆已在網站上公告小心遭詐騙的訊息)
但這樣就夠了嗎？
下一步的法律措施呢？
他還要繼續用同一個帳號營運嗎？
他的電腦中是不是仍有一堆的木馬？
或者他使用了某些分享軟體，像Foxy？
對於從事商業交易的電腦可以如此輕忽大意嗎？
該賣家是擁有2顆鑽石級的超級賣家
恐怕他是樹大招風+mail帳號被入侵
所以所有的資料都外洩了!!
這位賣家仍是沒有給我滿意的答覆
但也實在是無法要求對方太多
或許對方也正在為這樣的問題困擾著
或許對方的能力不足
從這個事件可以見到~
拍賣機制的賣家不是每一位都能安全的把關買家的資料
或許他們正是利用拍賣來作為釣買家資料的一個手段
買家的資料從他們的手上被洩露，他們的主張大多是-我也是受害者!
那買家如果真的因此受騙，難道賣家一點責任都沒有嗎？
這恐怕會成為拍賣機制的罩門
因為特定賣家的資訊保安能力不足，導致買家對其的不信任感
進而不消費
如此類似的事件繼續擴展，那消費者便不敢多冒風險
而轉向有公司體制營運的網路購物平台
當然最近許多大型的電視、網路購物平台資料外洩多有所聞
至少消費者可以提出損害賠償
但對於拍賣的賣家，卻很難著力提出同樣的要求
這將是兩者之間很明確的分水嶺
而拍賣平台的供應者，也應該正視這樣的問題
尋求一個更安全有保障的機制
不能說這件事不關他的事
因為他所供應的平台，先天上~
買賣雙方不是每個人都有足夠的資訊保安能力
所以拍賣平台的供應者應該担負起這樣的責任
提供讓人更安心有保障的交易環境
如果沒有，相信一旦話題發酵
許多重視個人資料隱私的消費者
會轉換消費習慣
當然，以私心來說，個人樂見這樣的情事發生
但以公眾的利益來說，這絕對不是一件好事
訂閱：
文章 (Atom)
發表文章
