用ASP實現電子賀卡 (轉)

用ASP實現電子賀卡 (轉)[@more@]

 

關鍵詞：

  電子賀卡的結構。(這僅代表我個人的在某一段時間的看法)。
  表ECARD
  賀卡的編號  ID  自動編號欄位
賀卡的標題TITLE
  賀卡的作者author
  賀卡的大類別catalog1
  賀卡的二級類別catalog2
  賀卡的型別cardtype  標明是flash卡，還是圖片(可能還有卡)
  大圖片的名稱image  當然可以是flash或是其他的名稱，可以包括路徑
  小圖片的名稱simage

表order_card，用來存放預定的賀卡。
  預定賀卡的id  經過編碼後生成提取卡片的key 
  大圖片的名稱image
  模板的名稱template  用來存放模板的名稱
  寄卡人名稱sender
  寄卡人sender
  收卡人名稱receiver
  收卡人的郵件receivermail
  是否收件確認confirm  寄卡人用來選擇是否要回執（我覺得這是最不必要的，還不如都給他回覆）
  寄卡時間senddate  可以選用日期型的資料，我認為日期是一個需要認真對待的問題，特別是在前段時間我在日期格式不斷遇到問題。

  接下來的分類列出賀卡，分頁顯示的問題，我想這裡所有的人瞭解的要比我深很多。關於整個程式的演算法實現，我還有一些想法，不知是否能構簡化操作，請大家幫我看一下。
1、賀卡的大數別和二級類別最好存放在另一張表中，產生一個自動編號的值存放在ecard表中，我這樣做是因為我認為對一個欄位進行判斷，要比對二個欄位進行判斷要快很多。在 SERVER中是不是這樣我不明白，我在access中這種差距是很明顯的。這樣子在對賀卡進行管理時可能比較麻煩，但畢竟次數不是很多。
2、顯示分類的頁就不要從庫裡取了,可以用手工作好，更好的方法用程式一次性生成了。各類別的分頁顯示，具體的賀卡頁面可以用程式生成，也可以用asp動態從庫中去取。在前一端時間我狂熱的迷上了靜態頁面，將所有的賀卡頁面和鏈結頁面都生成了靜態的網頁，但隨之出現了一些問題，要在靜態頁面中產生一些動態頁面的效果所付出的努力要大很多。同時由於程式的複雜性變大，頁面生成不夠自動，變成許多時候要停下手邊的工作去賀卡頁面，而且這樣做的複雜性變高，或許你會說這沒什麼難的，但想到如果另一個人接手這一工作，如果要對進行遷移，涉及的工作就會變得比較多了。由此我得出一個結論，如果你不是專職於這個賀卡程式，或者專門負責幾樣工作，如果你工作的不是一個專職的賀卡網站，我想動態頁面是一個比較好的選擇，當然如果你有更好的演算法來實現那就另當別論了。
3、如果你使用的是動態頁面，在分頁顯示所有賀卡時，在鏈結中可以包含template,image等引數，而不是僅僅傳遞一個id值，因為具體顯示賀卡資訊的頁有了這些值就可以顯示特定的賀卡，而不要再次運算元據庫了。
4、這裡我們使用wsh來實現定時髮卡功能，至於如何使用wsh來發卡我們在另一章來專門敘述。
5、由於使用了wsh來實現定時髮卡，我們可以配合或其他任何一個發信來傳送html格式的信件而不像sql mail只能傳送檔案格式的信件。在html格式的信中我們可以嵌入

這樣在comfirm.asp中取到這幾個值，不要操作任何資料庫就可以生成確認信了。如果你還要什麼其他引數讓它一併送回來給你就行了。
6、還有一個問題，純屬個人看法。如果我們直接傳送賀卡給，使用者就可以在一段時間內收藏賀卡，現在幾乎所有的賀卡網站都是傳送一個鏈結讓人去提取賀卡，這樣的話收藏的就很不方便了,只能看過就算了。為什麼網頁設計者會選擇這麼做呢，我想想法不外乎增加網站的訪問量，讓我們假設一下，如果每一位收卡人我們都要求他成為我們的會員才能閱覽賀卡，這樣不是更增加訪問量嗎，結果會怎樣呢？我個人的想法，一個網站應站在訪問者的角度上去看待問題，才能留住訪問者。
7、如果傳送html格式的賀卡給收件人，庫中的記錄就可以刪除了。但保守一點考慮，如果收件人採用方式收信，不能正確瀏覽賀卡時，應提供一個功能讓收信人可以透過輸入一個key來提取賀卡，這樣我們可能就不能刪除記錄，而應將它儲存至一個時限。
8、如果採用發給收件人一個key的方法，這個key可以透過對ID進行簡單的可逆的編碼產生一個key。
9、刪除賀卡時應先作標記，在一段時間後再進行刪除，以保證鏈結的完整性。
10、記住簡單就是美，在有限的步驟中完成所有的操作，讓每一步都完成一個特定的操作，再用一條紅線將它們連在一起，少用判斷，少用假設。

最後祝大家成功

事情總比你想像的要好。
TinTin