將程式邏輯抽離至XML描述

比起程式化或者是需要設計者藉由程式結構去製造，似乎有一些方向是偏向使用XML產生程式的邏輯。如果說一個系統大部分是由XML構成，真正撰寫程式的人會接受嗎？

以往我們將寫程式的能量耗在大量的結構化，物件導向，樣式的構思或設計，而如今可能換成使用描述的方式去編寫程式，似乎比較合乎那時候我的阿公提出來的概念，「程式不應該由人去寫」。那是否我們都應該將程式的邏輯或是變數抽離，以便讓更多使用者使用？

我從Hibernate的設計架構知道了實際上一個很好的系統，他會在可以改變的地方使用XML，如此好進行程式邏輯的改變（很像硬要將編譯式語言寫成直譯式語言，而造成如同PHP那樣連高中生都會寫）。但實際上，不久之前我還是堅持很多東西物件化，這樣因為我自己寫起來會覺得很輕鬆，但似乎那也只是限定在C＃上。

如果這樣子的話，似乎連libSrbCluster的撰寫也變得有相當的難度。或者我得說，這是一種經過分析的暴力法吧！不過這樣一來，就算不花太多時間去想流程，演算法，也會「看起來很複雜」並且很有深度，至少是經過分析過的。

但是以現在的觀念而言，XML程式設計有他原來所不能做到的，在怎樣說他也不能當作程式跑吧！

Linux pptp

基本上官方的How-to已經很詳細
我大概做一下安裝註記

proftpd + mysql + myftpadmin

• 介紹

proftpd:
http://www.proftpd.org/

中研院Grid Administrator Turtorial

http://www.twgrid.org/

Agenda:

http://lists.grid.sinica.edu.tw/cdsagenda/fullAgenda.php?ida=a0617

整體說起來應該主離有點失焦，本來是所謂的「管理」，卻沒見到他們提到有任何管理上的經驗分享。只是單純叫研究人員說出資料整理而已。

主題內容

相較於GT3或GT4的設計，LCG已經使用了GT2很大規模的整合，而不是單純分散的API或是指令介面，而且這些作法應該很早已前就有了。或許如果他們有心想做，gLite(前LCG套件)可以是一個將GT包得很好的東西，如此可以加快不熟悉的使用者，他們的開發。現在玩Grid的門檻很高，還是一個大問題。

是不是LCG對於關連式資料庫會有很好的整合？可以在R-GMA見到一點點有趣的東西。很可惜的是，他也只是換個方式來進行Grid資料的取得。

有關中研院與LCG

中研院在這一點可能偏向太專注在推廣了，LCG不見得是唯一值得推廣的Grid組織。不過很顯然地他們的策略相當好，實際上不太需要告訴使用者太多不關優缺點的問題，只要告訴他們，LCG的加入方法即可。因為他們的背後已經是一個很完整的組織了，加入我想只是會有好處而已。
但是我卻希望他們的推廣不要光是在實做上或是只是推廣，Grid的觀念其實還無法身為台灣人所接受，這個現象可以在P2P的世界中發現。大家都在想說要怎樣去哪裡取得資源，但是何時才會認真地想說自己得提供些什麼？
今天所聽到Deploy Team的結論是說，他們也只能夠身為Tier 1 Site，然後用很大的資源去吸引使用者分享了。

中研院目前是LCG的其中一個大Site，他們儘管可以推廣，但是究竟什麼時候Grid才是一個真正民生用的東西呢？

DoxyGen

 

DoxyGen的功能相當多，目前我已經使用在C/C++,C#,php,perl,javascript上
此軟體也附了GUI介面來快速產生Doxyfile
以下就對各種平台及語言的安裝做個介紹

 

平台

Windows
Linux
MacOS X
Solaris9
FreeBSD 

下載頁面

在可以安裝apt的平台上，你也可以找得到doxygen

 

---

               

語言共同特性

在這之前，你可以先參考以下文章
http://www.dev.idv.tw/wp/index.php?p=22
http://cdblog.twbbs.org/post/119/1657
http://www.longwin.com.tw/~jon/blog/archives/000299.html
這些文章會讓你先熟悉各種操作及撰寫方式。
本文主要在比較告種語言的撰寫過程及會遇到的問題。

各種語言有其不一樣的註解方式，不過遵循以下的註解方式，會讓文件比較不會出錯 。
注意到第二行開始的*都是有一個空白在前面的，雖然我曾嘗試過不依照這種法則，不過會發生有文件解析不出來的情況。對於各種語言，只要維持原本程式本身的註解樣式即可。但是註解要怎樣搭配各種程式語言，就是本篇文章要討論的。

JAVADOC_AUTOBRIEF

將這個選項開啟，你將可以用下列方式撰寫。

[code lang="cpp"]
/** 第一行是簡述 
 * 這邊開始才是詳文
 */
[/code]

否則你就必須在第一行加上@brief
 

C#,Java

C#和Java比較簡單的是，照著IDE預設撰寫的方式，就很容易地產生文件。
雖然有個工具可以輔助Visual Studio.Net 2003快速新增註解，叫做DoxyComment，不過在2005上跑是有問題的。

再設定Doxyfile的時候，還是要注意windows平台使用的都是絕對位置，所以更動專案的位置會導致問題。不過WorkingSpace卻不需要指定，重新開啟doxyfile就會自動決定。

php4

在這裡要討論的是比較舊的PHP4。
PHP說起來在Doxyfile的設定並沒有什麼太大的不同，但tag與phpDocumenter比較起來，就少了@var的tag。由於PHP4並沒有accessor(如public, protected)，所以要記得在private member的名字前加上" _ "來和public member做區別。Doxygen只會掃瞄到public method，不會掃到任何class內的public member。所以撰寫php的時候，還是比較像撰寫C++的習慣，會寫get,set來存取property，而var的宣告，就只能當作private property了。

PHP對於原生型態的判斷，如is_null,is_object等。如果是撰寫物件導向，就經常會遇到物件型態的判斷。
[code lang="php"]
function testInput($arg)
{
if(gettype($arg) == "object")
{
if(get_class($arg) == "domdocument")
print "input domdocument"
elseif(get_class($arg) == "domelement")
print "input domelement"
}
elseif(gettype($arg) == "string")
{
print "input is string"
}
else
{
print "input wrong type"
}
return $arg
}
?>
[/code]
就這個範例來說，在註解的時候，就比較不能像是php官方文件經常會看到的mixed arg這樣的註解方式。我還是比較推薦，使用以下的註解：
[code lang="php"]
/**
* @param arg
* DomDocument: 輸入DomDocument object
* DomElement: 輸入DomElement object
* string: 輸入string會自動建立...
* @return
* DomDocument: 原DomDocument object
* DomElement: 原DomElement object
* string: 原string...
*/
[/code]
如此便不會有輸入型態錯誤的問題，你的程式如果釋出的是函示庫，使用者撰寫你的函示庫也會比較得心應手。

Perl

Doxygen並不支援Perl，也是因為Perl的物件導向撰寫有大大的不同。BigSister團隊也使用doxygen，他們自己撰寫了perl doxygen filter，產生出來的文件會比較像是php撰寫的。

安裝相當簡單
[code lang="cpp"]
tar zxf doxygenfilter-1.01.tar.gz
cd doxygenfilter-1.01
perl Makefile.PL
make all install
[/code]

之後在你的Doxyfile內加上
INPUT_FILTER = doxygenfilter
FILE_PATTERNS = *.pm *.pl

註解的樣式也是要特別注意，開頭沒有兩個#加一個空白是不行的。
[code lang="perl"]
## @file
# 檔案的描述
# @class MyClass
# class的描述
package Some::Name::Space::MyClass;
## @cmethod new($arg,%opt)
# 建構子
# @param arg
# XML::DOM::Document: 傳入Document
# XML::DOM::Element: 傳入Element
# string: 輸入string會自動建立...
# @param opt
# [optional]Debug=>Integer，值可以是1.
# [required]Run=>Boolean
sub new {
my ($class,$arg,%opt)=@_;
...
}
[/code]

Perl也是很難做物件型態的判斷，所以還是要註解清楚。

SyncFusion UI Library

今天見識了一下SyncFusion的玩意兒，有些乍看之下很有趣，想想卻滿無聊，不過還是得找一天將真正有用途的介紹一下。

我不是一個喜歡追求別人寫好東西的人，不過真正有意義且有用途的函示庫，總是會流傳萬史。

UI Library

Docking
MDI,SDI Docking

Editor
AutoComplete：有用途不過不好看，似乎可以使用在很多不同的Box類元件上
ColorUIControl：小軟竟然連自家常用的東西都不釋出UI@@，有預設Web,System Color，不過我比較偏好Macromedia的
ComboBox系列: 有DataBinding功能，似乎如同Web上的需要
Currency系列：同樣有DataBinding，也有快速計算編輯器
DateTime系列：有DateTimePicker，MonthCalendar
DomainUpDown：有支援無上下限制的
TextBox系列：有支援數字格式化，autoComplele的，直接可取Integer或Bouble。MaskEdit支援正規表示法，也可以DataBind。
PercentTextBox總是會加個%任意文字，可能會有廣泛用途
Font系列：有ComboBox及ListBox
MuliColumnComboBox：比較特殊，在ComboBox裡有DataGrid
PopupControl：如同IntelliSence裡使用的彈出盒

Groupbar
MSN,XP,Outlook,VS.Net裡使用的各種群組顯示功能

LayoutManager：支援多種Layout

Menus
ControlBar：有點不同的工具列，不過還是有點Bug
MDI,SDI menus

Notification
GradiantPanel：有相當多的通知區域都是漸層彩色
ProgressBarAdv：也是多樣式的
SplashControl：可以擺在任何地方，包括systray，一樣有事件
StatusBarAdv：可以塞入不同的Control

TabbedMDI：可獨立使用的分頁MDI

TabPage：有XP或自訂樣式的

TreeView：支援各種樣式，動態產生，塞入各種Control

Wizard
WizardControl：就是精靈介面囉
XPTaskPane：XP樣式的工作導引



Shared Library

AppstateSerializer：支援XML,Binary,Ini,Registery的物件序列化

MouseController, RecordNavigator, ScrollControl：都是使用捲軸或滑鼠來取得絕對資料，然後及時繪製

其他函示庫

Calculate：類似簡易版Mathmatica，進行簡單的數學算式計算

Chart：支援Area Chart, Bar Chart, Box Whisker Chart, Bubble Chart ,Candle Chart ,Column Chart ,Column Range chart ,Combination Chart ,Hi-Lo Chart ,HiLoOpenCloseChart ,KagiChart ,LineChart ,PieChart ,PointAndFigureChart ,PolarChart ,RadarChart ,RenkoChart ,ScatterChart ,SplineAreaChart ,SplineChart ,StackingAreaChart ,StackingBarChart ,StackingColumnChart ,StepAreaChart ,StepLineChart ,ThreeLineBreakChart 支援WinForm和WebForm

Diagram：功能很多，有點誇張

Edit：強大的程式化功能，除了所有編輯器的功能外，可以針對自己定義的語言撰寫syntax

ExcelRW：不需要COM的函示庫，支援Excel BIFF 8 格式

Grid：有WinForm和WebForm，功能類似Excel

Grouping：針對資料進行分群與排序，輸出

HtmlUI：類似瀏覽器，不過是程式化地輸入Html

PDF：程式化的PDF產生器