cloudio™

老實說cloudio到目前為止對於linq並不是非常熟悉

也有實作過幾次，頂多是寫寫很簡單的小範例

上次重新安裝完XP之後

安裝完visual web developer2008

會自動安裝.Net Framework3.5


所以就不用在安裝2.0了

結果再啟動先前寫好的網站時出現

Server Application Error錯誤

用JavaScript寫物件有點像以前用ASP寫物件

都是沒有繼承、介面這些東西的

但是對於重度JavaScript使用者的PG來說

使用JavaScript寫物件真的是一件有用的方法

離開前一家公司一個月多了

目前cloudio待的公司是負責金融業專案的資訊公司

工作一樣是coding

今天同事問我一個問題

為什麼他的螢幕上出現這樣的錯誤訊息

今天聽到同事為了一個問題煩惱

"page_load後能直接觸發buttin_1的onclick事件？"

然後就聽到他們在不斷的煩惱

用JavaScript處理頁面圖檔失效 失連等情況發生

先前看了一本書後發現原來Response.Redirect的動作總共要client與server端來回2次

Response.Redirect它的動作像是這樣的:

client像server端要求Response.Redirect("新網址")

然後server端告訴我們的瀏覽器要轉到"新網址"

先前寫asp的時候大家都知道把常用的固定版面的群組另外寫一支asp的檔案

要用的時候就include他就好了

cloudio寫程式的時間不長
起步算是比較晚
直到2006年才初次接觸寫程式

response.end是以前寫asp很常用到的一個語法
以前常常會寫這樣的code

寫網頁的時候有時會有這種需求
利用javascript來連結另一份.js的文件

在做web頁面的呈現時常常會需要做一個亂數排序資料的需求

這邊clouio就不在server端做

而選擇直接在client實做

有時候客戶不一定會讓我們挑要用什麼當資料庫

畢竟開發的程式是客戶的

環境也是客戶提供的

這陣子網頁工程師最常碰到的問題應該是"你的網站有沒有做SQL Injection的處理"
因為最近SQL Injection實在是鬧的雞飛狗跳
其實這也不算是軟體的漏洞或是系統的問題
只要是寫程式一定都要再三小心

那天在問同事寫網頁圖檔失效的處理
原本只是想提一個簡單的做法
結果意外扯到檔案上傳後命名的方式
同事說他檔案上傳後會重新命名
我心想"恩..本來就要重新命名阿"因為會牽扯太多問題了
結果同事的重新命名方式是"年_月_日_時_分_秒"

使用datepicker最主要的目的就讓使用者能夠更輕鬆的選擇日期
所以datepicker如果沒有設定的彈性的話的就沒什麼用了
datepicker預設可選的年份是你目前選中的年份+-10年

一般在網路提到泛型處理常式上找到的文章大多都是用來處理動態輸出圖片
cloudio本身就比較喜歡把泛型用來做AJAX後面的那支處理程式

通常我們在寫程式常常需要使用者填寫日期格式
最常見的日期格式就是三個下拉式清單讓使用者選擇年月日
或是直接給一個text欄位讓使用者手工輸入
這兩種做法我們在接到值送往資料庫前都必須在確認一次是否接收到的值是符合日期格式
以免程式出現錯誤造成安全性漏洞

早期我們在寫asp的時候為了達到使表格的每一列資料有所區隔通常會作成
單數列一種樣式
雙數列一種樣式
這樣看起來會比較輕鬆
每一筆資料分的很清楚