Tag

階層架構被認為是人類最偉大的發明。它的原則是每一個item都可以被放在特定一個的category下。這可以讓人類依category很容易的找到想要找的item。時至今日，這個假設已經不再合用。很多情況下，一個item已經無法被歸類在特定一個category下。難道這個item就可以被同時放在2個以上的category中?不，不可以，這會有資料一致性的問題。
於是就有人不再以category去尋找資料。他們直接去搜尋item。偉大的google自始至終都一直強調搜尋演算法，如何才可以快速的找到想要的資料。很明顯的，google做的還不夠好，因為每次我在搜尋時總有好幾百萬筆；不過這也不能怪goole，因為連我自己要找什麼都不太清楚，怎麼能要求那種電腦演算法能給出我一個正確的東西。然而這卻是在人類使用category時，會面臨的情境：我就是不知道我要找的是什麼，所以才用category去找。....有點扯遠了。回到開始有人直接去搜尋item...。
搜尋的問題可以用「直接搜尋item」與「提高演算法精確度」來解決。但階層提供的功能不只是只有幫助搜尋，他也為item真的提供了分類的功能。這個分類並不是為了讓item可以快速的被搜尋到，而真的只是幫item做歸類。那如果沒有了category，分類怎麼辦?於是tag這種東西就出現了，它幫item做了一個分類，認為這個item應該屬於這個category，我就給你屬於這個category的tag。就如同所謂「真的分類」的功能，tag也就「真的只是分類」。那好像是屬於這個category又好像是屬於那個category的item怎麼辦?沒關係，我就給你這個category的tag與那個category的tag。這樣就解決了1個item隸屬於2個category，卻又不會造成資料不同步的問題。

STRUTS使用Module?

Struts與Tiles我就不多說了。我們在設計網頁時，需要決擇在一個網頁裡在不同的輸入部份應該使用相同的一個form或是不同的form。一個例子是畫面上右上角的使用者登入輸入帳號密碼的欄位與主畫面功能的資料輸入欄位。使用者登入欄位always會出現在那裡讓使用者可以在任何時候登入(當然也可以設計成只是一個連結讓使用者可以在任何時候連結到登入頁面)。在這樣的情況下，設計者必須決定該使用一個form或不同的form。
再加上另外一個條件：我們在開發時使用不同的module。Struts可以將不同的action與form寫在多個struts-config檔裡。這有2種情況，1種是真的只是寫在多個struts-config檔裡，另外一種是以module的型態來設計。一但使用了module，request中module的轉換都要使用switchAction(看不少文件都這麼寫...，但我本身也試過使用module卻不使用switchAction的情況)。在同一個畫面有必要使用2個form的情況下，struts action與form的區分我建議使用第一種方式：將action與form的設定分散在不同的struts-config 裡。因為當登入部份與主畫面的form屬於不同module時會無法執行；在switch module後，整個頁面就是那個module了，不可以有另外一個module的action path或form存在。當然，如果前面這個假設條件不成立的情況下，當然是使用module了。如果要說用不用module有什麼差別，我認為就如同JAVA的Class有沒有放在package裡一樣；如果你可以保證class name怎樣都不重覆，又在檔案不管有多少的情況下，都可以找到想要的檔案，那package的用處可能也不太大了。

做想做的事與得到想要的事

最近在讀的一本書：「先別急著吃棉花糖」，說明著延遲享樂才可以成功。我覺得這與利息的產生有同工異曲的妙用：你現在所做的事，隨著時間，在未來會有會更高更多的回饋。現在盡情放開享受生活，以後就會有不枉此生，不會有年少留白的遺憾(可能會是三餐不繼的覺得不枉此生)；現在努力，未來就會功成名就財富滾滾而來(可能再也沒有機會與體力四處遊山玩水)。換個角度來看，也就是說為了以後的回饋，現在必須要放棄一些事情，來換取未來的價值。
然而不管怎麼說，我認為最重要的還是要知道自己想要的是什麼。因為是自己想要的，所以未來不會後悔。現在努力工作，未來就不會後悔虛渡青春，因為得到自己想要的財富，反之亦然。這起因在於現在想做的事總與想要的事互斥，現在不放棄想做的事，未來就得不到想要的事。當然互斥是一個一種條件假設，並不是絕對。像有些人真的很喜歡工作，也可以因為工作而賺大錢，我想這種人應該很快樂吧(並非所謂的工作狂，工作狂之所以狂工作是有理由的，喜歡並沒有理由)。
我常在想，如果想做的事沒有副作用，可以直接導致想要的事的話，那該有多好。

BeanCoomparator

有沒有寫過自己的bean呀?自己寫的bean會有一個問題(當然不只一個問題)，就是排序。一般來說，要對物件做排序，要嘛是實作comparable的compareTo方法，要嘛是另外再針對每種不同的bean在Collection裡丟入Comparator。實作compareTo就顯得不夠彈性，另外再寫Comparator就顯得有些麻煩。但是，現在jakarta-commons-beanutils的BeanComparator可以讓你很輕鬆的建立comparator。
先看一下情境：假設我現在有一個menu物件，menu有子選單，是menu的一個property，型態是Set，名稱是menus；另外有一個orderSeq property，現在就是打算要讓取出來的menus依照orderSeq來排序。從資料庫產生物件時因故(反正就是有原因讓我們不能取出記錄時做排序，例如程式是別人寫的，programmer不想再去改之前寫的程式碼....)無法排序。現在我要對menu作排序。
先看一下代碼(唔..可能是最近老是在看大陸文章，台灣的講法是「程式碼」)：

public class Menu implements java.io.Serializable {
private Long pk;
private Set menus = new HashSet();
public Set getMenus() {...
public void setMenus(Set menus) {...

排序的程式碼：

Set menus= m.getMenus();
BeanComparator bc = new BeanComparator("orderSeq");
Collection returnedMenus = new TreeSet(bc);
returnedMenus .addAll(menus);

這樣所產生的returnedMenus就會依照orderSeq property來排序了。