沉默了近一個(gè)月，終于有時(shí)間寫B(tài)log了。這些日子除了忙于工作還抽時(shí)間看Flex，發(fā)現(xiàn)ActionScript的編程思路和SWT、Swing有很多相似之處，而且語法也和Java很相似。總之我對(duì)Flex極為看好。今后可能要穿插地寫些Flex的Blog了:)
前寫日子看留言，有人說VB、VC的界面設(shè)計(jì)都是將界面保存成一個(gè)資源文件，這樣能完全做到界面與邏輯的分離。我從事UI設(shè)計(jì)以來，用過像JBuilder、NetBeans的GUI拖拽工具，但是實(shí)現(xiàn)方式均是生成Java代碼而已，這樣不但容易造成偶合，而且工具生成的代碼往往冗長。從我的項(xiàng)目經(jīng)驗(yàn)來看，UI部分大多數(shù)代碼出現(xiàn)在組件的創(chuàng)建與布局這一環(huán)節(jié)，如果你使用Matisse將組件布局設(shè)置成GridBagLayout或GroupLayout，再隨便拖拽兩三個(gè)空間上去，觀察下代碼，很長。而且不了解GridBagLayout和GroupLayout的非專業(yè)UI設(shè)計(jì)人員很難讀懂。
“將界面保存成一個(gè)資源文件”類似想法早就有了，一直想通過xml配置將組件生成而非hardcoding。下一篇的文章將作詳細(xì)介紹。在此之前，先解決一個(gè)bug，關(guān)于自定義布局類FormLayout和CenterLayout。這兩個(gè)布局的preferredLayoutSize方法實(shí)現(xiàn)如下：
public Dimension preferredLayoutSize(Container target) {
return target.getPreferredSize();
}
其實(shí)是不對(duì)的，如果這樣的話當(dāng)容器沒有設(shè)置setPreferredSize的話，運(yùn)行時(shí)會(huì)產(chǎn)生堆棧溢出錯(cuò)誤。解釋下緣由。
java.awt.Container的getPreferredSize方法定義如下
public Dimension getPreferredSize() {
return preferredSize();
}
追蹤到preferredSize：
@Deprecated
public Dimension preferredSize() {
/* Avoid grabbing the lock if a reasonable cached size value
* is available.
*/
Dimension dim = prefSize;
if (dim == null || !(isPreferredSizeSet() || isValid())) {
synchronized (getTreeLock()) {
prefSize = (layoutMgr != null) ?
layoutMgr.preferredLayoutSize(this) :
super.preferredSize();
dim = prefSize;
}
}
if (dim != null){
return new Dimension(dim);
}
else{
return dim;
}
}
發(fā)現(xiàn)如果prefSize為空等原因的話，可能返回布局類的layoutMgr.preferredLayoutSize方法。所以說，如果在布局類的preferredLayoutSize實(shí)現(xiàn)中返回容器的getPreferredSize，那么很可能陷入函數(shù)調(diào)用的循環(huán)中，最終導(dǎo)致堆棧溢出程序終止。類似的還有minimumLayoutSize和maximumLayoutSize方法，修復(fù)的實(shí)現(xiàn)如下：
public Dimension preferredLayoutSize(Container target) {
target.getPreferredSize();
synchronized (target.getTreeLock()) {
return new Dimension(0, 0);
}
}
預(yù)計(jì)周末發(fā)表《通過xml配置文件定義及布局組件》