Install trac on ubuntu with multi-project

晚上在Ubuntu上把trac 裝好了，因為clearsilver的so link 會遇到一些問題，所以，把過程記錄下來。

安裝軟體套件

sudo apt-get install trac apache2 libapache2-svn

建立trac環境

sudo mkdir /var/lib/trac

sudo chown www-data:www-data /var/lib/trac

設定apache (enable sites)

ScriptAlias /trac "/usr/share/trac/cgi-bin/trac.cgi"

<Location "/trac">

SetEnv TRAC_ENV_PARENT_DIR "/var/lib/trac"

</Location>

Alias /trac/chrome/common "/usr/share/trac/htdocs"

<Directory "/usr/share/trac/htdocs">

Order allow,deny

Allow from all

</Directory>

做到這邊，trac 環境應該可以正常的運作了，如果需要使用者認證的話，則需要在apache的設定中加上以下設定 (Multiple project 環境)

<LocationMatch "trac/[^/]+/login">

AuthType Basic

AuthName "Trac"

AuthUserFile /somewhere/trac.passwd

require valid-user

</LocationMatch>

重新啟動apache，trac環境就可以正常運作了。

接下來，只需要在新增專案的時候，在/var/lib/trac下用trac-admin 的initenv command建新的trac repository了。

struts 2: field validation and type conversion

一般web 應用中，很基本的一個功能是參數的驗證(validation)，而在struts 2中，這個功能是透過validation來達成的。但是，在驗證之前，struts 2會先做type conversion 的動作，以確定輸入的參數能夠滿足action 中各個properties的需求。所以，interceptor的執行順序是

1. 型別轉換 (type conversion)
2. 參數驗證 (validation)

如果在型別轉換時就發生錯誤的話，相同的欄位就不會進行參數驗證。我就是忽略了這個順序，才搞了二天。

舉例來說，如果有個property 是 setDate(Date theDate)，在zh_TW的locale中，預設的日期格式是mm/dd/yyyy，我想在為這個欄位加上validation, 於是，在我的Action-validation.xml中有下列的一段程式碼：


<field name="date">
<field-validator type="regex">
<param name="expression"> ...</param>
<message>wrong format for field date</message>
</field-validator>
</field>


但是，當格式錯誤時，regex卻不會抓到錯誤，問題就是出在type conversion 的interceptor 先運作了，所以總是會出現type conversion 的錯誤訊息 : "Invalid field value for field "date""，所以，對於非String 型態的property，比較有意義的validator只剩下required、date、int這幾個有意義，其他的意義都不大。

那接下來的問題就在於，怎麼把"Invalid field value for vield ..." 這段訊息換成我們想顯示的訊息。這必需透過struts 2的I18N機制來達成，根據AnnotationXWorkConverter文件中提到的，可以在ClassName.properties中設定 invalid.fieldvalue.欄位名稱，來設定特定欄位的conversion error錯誤訊息，如果要改變預設的訊息的話，則可以透過設定global的I18N屬性xwork.default.invalid.fieldvalue 來達成效果。

sturts 2 validation and action property

今天又犯了個豬頭錯誤，我有兩個Struts Action，程式碼類似這樣:
public class ParentAction {
protected long property;
...
public long getProperty(){
return property;
}
}

public class ChildAction extends ParentAction{
public void setProperty(int property ){
this.property = property;
}
}

當我對ChildAction 加上required validation時，問題就來了，不論我輸入的是什麼值，validation interceptor總是告訴會回報property is null，找了半天，一路trace到Ognl層，才發現問題出在，透過reflection API取得property 的method descriptor時，因為setProperty的參數型態和getProperty的參數型態不符，而getProperty又在parent，所以會只認getProperty，而把setProperty(int) 當作是一個overloading method，以致於無法設值進去，只要把setProperty 由setProperty(int)改成setProperty(long)，就又能夠正常運作了。

這樣的錯誤，只能說是自己不小心造成的，但是，這種錯，應該會常常發生吧，下次，得把這類的檢查也加到test case中。

下車再上車?

以前的同事pj曾經說過一個笑話，一群人開車到郊外踏青，在差不多算是荒郊野外的地方車子故障了，一群人急得想各種辦法要把車子修好，但是都徒勞無功，最後，一位在微軟工作的軟體工程師說話了：「我們把車子熄火，全部的人下車，再上車試看看，可能就沒問題了。」凡是用過電腦的人，多多少少會遇到類似下車再上車的狀況，對像可能是特定的應用程式，也可能是整個作業系統，怎麼找就是找不出問題，但是，把程式重開或是重開機之後，問題就不見了。而開發人員遇到這種狀況的機會又比一般的使用者來得高。

這種狀況，常常是因為系統在開發過程中沒有考慮到一些特定的狀況所造成的。但是隨著作業系統愈來愈複雜，今天，除了特殊的應用之外，單工的作業環境已經愈來愈少見了，導致要在開發階段就考慮到所有的狀況已經是愈來愈不可能了。為了因應這種狀況，近代的程式語言大都包含了例外處理的機制，這個機制最主要的目的就是讓程式在遇到開發時期未考慮到的狀況時，能夠死得漂亮一點，死得優雅一點，最低限度，要讓使用者知道，程式已經死了，而不是讓使用者去和一個不穩定狀態的系統打交道。

例外處理，是程式設計的一個很重要的課題，雖然有些人認為例外處理讓部份程式流程更不容易被追蹤(trace)，但是不可否認的，在支援例外處理的程式中，程式碼可以以更容易被人類讀懂的方式來表示，而不是一長串的if/else if /else。畢竟，程式碼除了建立系統之外，也是程式設計師之間最主要的溝通工具。如果說，少男漫畫中的主角是用拳頭交心，那程式設計師就是用程式碼交心了。