線上訂房服務-台灣趴趴狗聯合訂房中心
發文 回覆 瀏覽次數:1452
推到 Plurk!
推到 Facebook!

資料感知元件與查詢介面的掙扎

答題得分者是:P.D.
g9221712
高階會員


發表:145
回覆:344
積分:162
註冊:2006-07-06

發送簡訊給我
#1 引用回覆 回覆 發表時間:2007-04-08 22:51:51 IP:220.134.xxx.xxx 訂閱
各位前輩及板主大人:
不知道前輩您的查詢表單,大家都是怎麼開發的,我看到的開發的方式有如下幾種:
1.專屬查詢表單介面:
在編輯表單上,開啟表單,在查詢表單上設定可查詢的條件,然後透過移動紀錄的方式
將編輯表單的紀錄,移動到符合條件的紀錄上!

2.通用查詢表單介面:
在編輯表單上,開啟表單,在通用查詢表單上設定可查詢的欄位條件(一般都是資料表的
所有欄位,需判別資料欄位型態,且另外一個議題是資料表上系統的欄位需隱藏,並且有
權限不同、需過濾可以查詢欄位的安全問題),然後透過移動紀錄的方式將編輯表單的紀
錄,移動到符合條件的紀錄上!

3.混用型查詢表單介面(我在鼎新TTOP上看到):
在編輯表單上,按下查詢按鈕,則編輯表單能看到的所有欄位,都能設定條件加以查詢!

問題來了:
我目前第一種和第二種表單都有轉寫,而這三種查詢表單介面優缺及限制如下:
1.專屬查詢表單介面:
優點:開發較簡單
缺點:較為費時,且需管理表單變多!
2.通用查詢表單介面:
優點:且一表單通吃,使用非常簡單!
缺點:開發時複雜、且有權限管制問題,而且類似SQL語法產生器,使用者輸入條件時不直覺!
3.混用型查詢表單介面
優點:且一表單通吃,使用非常簡單,所見即能查!
缺點:開發時複雜、且欄位若使用資料感知方式,需要額外使用物件,最為輸入條件用!

目標:
各位前輩其實我想達成的是第三種表單的開發,因為這樣可以一次解決查詢權限和要額外開發查詢介面的問題!
而輸入元件我也寫好了(但資料輸入元件使用資料感知方式),我在想是否要在複合元件內多放一個查詢條件
專用的editbox和DateTimePickup元件,但是若加上這些額外的元件,假設表單上有30欄位,則表單上得物件,
會多出很多,不知道這樣開發是否有問題!

當然我知道有另外的方式,就是資料輸入元件,都不要使用資料感知的方式,全部都是動態填入! 真是頭痛~
請前輩們給予建議吧~ 又卡了好久!


------
「人們所以覺得寂寞,是因為他們會築牆,卻不會搭橋。」
程式寫的越久,卻發現自己越來越不會寫程式!
bruce
中階會員


發表:19
回覆:121
積分:83
註冊:2002-04-16

發送簡訊給我
#2 引用回覆 回覆 發表時間:2007-04-09 09:28:23 IP:203.70.xxx.xxx 訂閱
如使用專屬查詢,可依表單分類,建構查詢類型,也就是說將查詢單獨歸成一個類別來設計,以解決設計繁瑣問題,同時不同的表單也很方便,可以配置不同的查詢方式,所以不管是通用或專用,他就是查詢類別的一種。

像鼎新的查詢方式,可以寫一個類別,找出Form上的TDBEDIT物件,再用TEDIT取代,達成查詢目的,這也是可以歸類成查詢的一種。所以我覺得是否繁瑣,不在於專屬與否,而在於是否能建立一個適用的類別。
g9221712
高階會員


發表:145
回覆:344
積分:162
註冊:2006-07-06

發送簡訊給我
#3 引用回覆 回覆 發表時間:2007-04-09 09:31:02 IP:220.134.xxx.xxx 訂閱
講的真棒~看來我需要多一點智慧!哭泣中!
------
「人們所以覺得寂寞,是因為他們會築牆,卻不會搭橋。」
程式寫的越久,卻發現自己越來越不會寫程式!
bruce
中階會員


發表:19
回覆:121
積分:83
註冊:2002-04-16

發送簡訊給我
#4 引用回覆 回覆 發表時間:2007-04-09 12:23:51 IP:211.21.xxx.xxx 訂閱
只是提供一個小小的意見,g9221712兄,您太客氣了。
kevin2004
資深會員


發表:18
回覆:463
積分:416
註冊:2005-05-29

發送簡訊給我
#5 引用回覆 回覆 發表時間:2007-04-09 21:02:24 IP:61.231.xxx.xxx 訂閱
這麼認真寫了這麼大一篇,小弟研讀思考中,再來請益
------
Kevin
P.D.
版主


發表:603
回覆:4038
積分:3874
註冊:2006-10-31

發送簡訊給我
#6 引用回覆 回覆 發表時間:2007-04-18 01:39:21 IP:61.67.xxx.xxx 未訂閱
我有一點疑問?
既然您都已經把可能的寫法的優缺點都寫出來, 也做了很詳細很好的評估, 何不就您自己的案子選擇合用的去做, 因為這樣的問題是沒有解答的, 每一種寫法可能會適用不同的場合, 重點是你希望把您的構想以那一種方式提供給使用者用才是最好的, 至於說會不會有問題做了就知道, 如果我告訴您第三種會沒有問題, 其實那是自欺欺人, 有誰敢保證那一個方法是ok的, 您說是吧?
g9221712
高階會員


發表:145
回覆:344
積分:162
註冊:2006-07-06

發送簡訊給我
#7 引用回覆 回覆 發表時間:2007-04-18 03:40:40 IP:220.134.xxx.xxx 訂閱
P.D.前輩:

我在掙扎的是,若想用貼近使用者感覺得介面,則我能採取的策略只有兩種:
1.我捨棄資料感知元件的方式,所有的資料我必須自行填入!
2.若採用資料感知元件的方式,則我必須於複合元件內多塞一個edit元件!

因為我的目標是我想做出類似表單的查詢介面,但又想減少查詢介面的開發過程
但是我不知道每個元件都多塞一個EDIT元件,對整體系統是否有影響,所以我
特來版上請教,當然打出來也是對自己的想法整理,因為怕我自己亂做一通!

想請教版上前輩和高手,給予一些建議! 感謝!
------
「人們所以覺得寂寞,是因為他們會築牆,卻不會搭橋。」
程式寫的越久,卻發現自己越來越不會寫程式!
P.D.
版主


發表:603
回覆:4038
積分:3874
註冊:2006-10-31

發送簡訊給我
#8 引用回覆 回覆 發表時間:2007-04-18 16:21:35 IP:61.67.xxx.xxx 未訂閱
您好:

寫程式沒有經過陣痛是很難成為自己的經驗, 我沒有其他的意思, 因為由你的論述中我覺得你已經具備很清楚的思維與架構, 剩下的只是客戶的感受而已, 其實我的經驗, 很多客戶是我們給他們什麼, 短時間內他們就是很老實的去用, 不會有十分特殊的癖好, 但人的欲念是無止盡的, 一段時間自然會對使用的東西有很多想法, 所以你現在不管考慮如何做, 對客戶來說我們看的是結果論, 好用就好, 客戶才不管你用什麼方法, 用什麼介面呢! 至於你說不用感知作法, 這比較接近於以前DOS的設計概念, 也不是不好哦! 只是設計者要多費很多心去處理資料變數的考量, 用感知也不一定好, 因為一切自動化, 有些狀況我們並不容易確實掌握到, 所以我認為這無須掙扎, 就挑一個做下去, 因為你現在只限於心中冥想結果論, 何不先行動, 有問題大家可以討論的, OK?
系統時間:2024-05-19 14:14:22
聯絡我們 | Delphi K.Top討論版
本站聲明
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。
2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。
3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇!