ZK-1509 的故事

ZK-1509 是 Vincent 大師在測試 layout 的時候發現的： 如果 Cardlayout 把 v/hflex 都設成 1， 然後放在 Hlayout 裡頭，當 browser 調整大小的時候，Cardlayout 就會消失！

怎麼可能！Cardlayout 很 nice 的，這其中一定有什麼誤會！
謎之聲：那是因為 Cardlayout 是你寫的吧？ [指]

實際測試發現並不是 Cardlayout 的問題。 如果 Hlayout 裡頭塞設了 v/hflex 的 Div 一樣會不見， 或是不用 Hlayout 而用 Div 塞 Cardlayout 也不會出問題。 所以不是 Cardlayout 而是 Hlayout 的問題... 啊哈哈哈哈... [逃]

那麼，問題出在哪裡呢？flex 機制（下略數十字 [逃]）在 beforeSize() 會要求 widget 作 afterResetChildSize_()。 Hlayout 的 afterResetChildSize_() 寫在 Layout.js，以純邏輯的講法會把 Hlayout 的大小設成 0， 這樣在後續的流程（應該是 fixFlex()）才會重新計算 size。

原本的作法是將 Hlayout 的每個 child 抓出來，把 kid.$n('chdex').style.height 設成空字串。 chdex 是 ZK 當中的慣用字，parent 裡頭裝 child 就會多掛一個 id 是 CHILD_ID-chdex 的 div， 這個 div 的變數就會用 chdex。child 會塞在 chdex 裡頭，這樣某些操作會比較容易 （不要問我是哪些操作 [死]）。

重設 child 的 chdex 看起來似乎沒啥問題，邏輯上也似乎合理，不然這個 bug 也不會這麼久才炸出來？ 把 Hlayout 改成 Vlayout，完全不會發生消失的現象。 比對兩個的 DOM 差異，發現又是 inline-block 造成的問題， Hlayout 有設定 display:inline-block 而 Vlayout 沒有。 這導致後頭在判斷是否要作 fixFlex()、檢查 visible （下略數十字，實在沒辦法搞懂什麼時候要用哪招判定 visible ）失敗， 導致根本不會作 fixFlex()。

於是就卡關了...... Orz

後來 Vincent 大師在對付 ZK-1569 發現，重設 chdex 雖然合理，不過重設 child 應該更合理一點。 而且這樣一來問題也會消失；跟 ZK-1569 很類似的 ZK-1509 應該也可以比照辦理。 於是把 afterResetChildSize_() 原本 chdex = kid.$n('chdex'); 改成 chdex = kid.$n() 就結案了。

至於為什麼當初要設定 CHILD_ID-chdex 而不是設定 child 本身？ resetSize() 要不要也比照辦理？ 我們下回分解... （謎之聲：你的下回是來生吧...... [指]）

ZK-1309 的故事

正確來說，ZK-1309 應該稱之為 onFloatUp 的故事...... [淚目]

故事發生在 modal window 當中如果用了 Clients.showNotification()， 要再對 modal window 作 drag 的時候，覆蓋畫面的 mask 就會消失， 在 drop 的時候才又出現；令人傻眼的是，如果繼續 DnD，就又恢復正常行為。

ZK-1220 的故事

ZK-1220 （又）是一個抓蟲三刻鐘，除蟲三秒鐘的 issue。

故事是這樣的，在 ZK 6.0 之後 InputElement/InputWidget（Java/JS）增加了 instant 這個 attribute。 當 instant="true" 的時候，所有的改變會馬上送到 server 端。 如果 end-user 在有設定 instant 的 Textbox 輸入之後馬上（更精準地說是 350ms 內）改變游標位置， 則游標還是會回到最尾端。

ZK-1441 的故事

ZK-1441 的故事有點 critical，基本上他一定要「快速連續切換 tab」才會有效果，正常操作行為很難遇到這個狀況。

WTF......

終究是名副其實可以複製的 bug，也就只能硬著頭皮上。

Tab._sel()
    Tab._setSel()
        Tabpanel._sel()
            jqzk.slideDown()，在這裡 this.dimension() 會取到錯（較小）的值

基本上無力去探究 jqzk.dimension() 為什麼會取到不對的值，畢竟正常情況下運作是正確的。 只能猜測是因為 animation 的原因導致 jquery 錯亂？

中間試過 setTimeout() 來等 animation 完再換下一個 tab 操作，不過失效（細節略 XD）。 後來只能把腦筋動到弄一個 flag： Tabbox._animating，在呼叫 slideDown() 之前設定， 透過 slideDown() 的 callback function 來拿掉，然後進入 Tab._sel() 的時候用這個判斷是否要擋掉不做。

至於為什麼不用 zk.animating()，那是因為只要有其他 animation 在跑（例如檔案上傳的 Progressmeter）， 就會判定不過而被卡掉。（反過來說，用 zk.animating() 來作某些事情的都有這個隱憂？）

套句死神裡頭的台詞（其實我沒看過）：「其實我不想用這招的」， JS 對 field 作 CRUD 實在太方便了，一點控管辦法也沒有，只好多寫幾行註解結束這個 issue。

ZK-1430 的故事

ZK-1430 真是一個曲折離奇的故事，分上下兩集來講好了 XD

上集：召喚 v/hflex="min"，結束這個 issue

起手布局是一個 bandbox，然後 bandpopup 當中塞了一個 listbox。 希望這個 listbox 只顯示 5 個 row 的大小，所以設了 rows="5"， 但是 bandpopup 不會跟 listbox 一樣大，自己長自己的大小。

算 bug 嗎？

ZK-1411 的故事

有人說：我怎麼對 auxheader 設定 width 都沒有用？ 這是 bug 吧？

一開始還真的以為是 auxheader 可以設定 width，只是剛好他人品爆發寫了奇怪的 code 踩到雷 （是說他提供的 code 實在... 唉...）。結果我 try 了一下，發現基本上 auxheader 真的完全不會管你 width 設了啥， 統統給你平均分配。

btw... 中間還耍了這樣一個白痴 code

<grid width="900px">
    <auxhead>
        <auxheader width="300px" label="aux 300px" />
        <auxheader width="500px" label="aux 500px" />
        <auxheader label="aux" />
    </auxhead>
</grid>
<!-- 喔喔喔喔... 難道只有第二個的 width 才會有問題嗎？ [死] -->

不帶任何希望地爬了一下 ZK 文件（總比去 source code 慢慢 farm 來得好 [逃]）， 結果在 component reference 找到這段：

The other limitation is that the width of the Auxheader component depend on the Column component. Thus, if you'd like to specify the width in the Column component, it means it will take some space even when there are no label in all Column components.

除非去質疑 spec，不然這個 issue 是不成立的。 但反過來說，為什麼不在 auxheader 試圖設定 width 的時候炸 exception 呢？ 所以我改去發了 ZK-1422，至於後續如何發展，請待下回分解（慢慢等吧你 XD）。

這個 ZK-1411 的故事有點像是來騙文章數的 [毆飛]。

ZK-1391 的故事

這是一個說難絕對不難，但是卻讓我這個低能苦手著實糾結了好一陣子的 issue。

故事很簡單，就是在 Window 這個 component 在某些 mode 下可以用 left、top 設定位置， 當然也可以設定 visible 來設定顯示與否。 怪事就這麼發生了（我覺得更怪的是：為什麼到現在才有人踩到 XD）， 如果一開始 visible="false"，另外只單純設定 left 或 top 而沒有設定另外一個， 那麼在重新設定成 visible="true" 時，設定的 left / top 就會沒效果，直接跑到 (0, 0) 的位置。 但是假若 left 跟 top 都有設定，又能顯示正確結果。

第一直覺是 JS 那邊的 setVisible() 出了什麼紕漏，結果在 _updDomPos() 裡頭繞了很久，發現根本不是那麼一回事情。 毫無頭緒之下只能一步一步慢慢跑，看 jq("#"+uuid) 的 style 什麼時候被改掉。 結果是在 setVisible(true) 之後，bind_() 會去呼叫 _doOverlapped() （Vincent：早就跟你說了阿 [指]）， 這裡頭原本的邏輯是：

if (!pos && (!n.style.top || !n.style.left)) {
    var xy = $n.revisedOffset();
    n.style.left = jq.px(xy[0]);
    n.style.top = jq.px(xy[1]);
}

也就是當 Window 沒有設定 pos 而且 top 或 left 有一個沒有設定， 就會去呼叫 revisedOffset() 來重新決定位置。 至於 revisedOffset() 怎麼運作的根本不重要－－因為這傢伙根本還沒出現在 DOM 當中（不然幹麼呼叫 bind_()）， 也就根本取不到值；這也可以說明了如果同時設定 top 跟 left，那麼就不會進來這一段啦。 在不知道當初為什麼會寫 !pos && (!n.style.top || !n.style.left) 的前提下，也只好這樣改來避開了：

    if (!pos && (!n.style.top || !n.style.left)) {
        var xy = $n.revisedOffset();
        if (!n.style.left) {
            n.style.left = jq.px(xy[0]);
        }
        if (!n.style.top) {
            n.style.top = jq.px(xy[1]);
        }           
    }

唉... 好心的大爺們... 多寫點註解阿...... Orz

ZK-1380 的故事

來寫一篇 ZK-1380 的報告。

故事開場還是來自一個 forum thread。 developer 發現他要 forward 到放在 zk 底下的 zul 就會炸 HTTP 404， 但是只要不是放在 zk 底下就沒問題，而且觸發條件還是得在 Tomcat 7.0.29 以後的版本。

結果我在 Tomcat 7.0.27（剛好手邊就是這個版本 XD）可以重現這個問題， 但是 Jetty 6.1.26 不會...... 雖然很怪不過還是去發 issue 了。

因為沒有稿費，所以直接快轉到跳結果：這是 Tomcat 7.0.29 以後改變 webapp 的啟動流程。 changelog 的原文是這樣寫得

As per section 1.6.2 of the Servlet 3.0 specification and clarification from the Servlet Expert Group, the servlet specification version declared in web.xml no longer controls if Tomcat scans for annotations. Annotation scanning is now always performed - regardless of the version declared in web.xml - unless metadata complete is set to true.

而 ZK 在 6.0（應該） 之後有用 web-fragment.xml 來註冊 /zkau 跟 /zk 的 servlet mapping， 以支援 servlet 2.5/3.0 的規格。 在 Tomcat 7.0.29 之後就一定會去讀 web-fragment.xml， 所以 /zk/* 就會被 DHtmlLayoutServlet 給處理掉。

所以如果 forum 的那個原 po 好死不死把 /zk 改成 /zkau 基本上也是一樣會炸 HTTP 404。 至於為什麼我在 Tomcat 7.0.27 也能重現這個問題呢？ 因為我測試的 project 當中，已經把 web.xml 當中的 <web-app> 設定 version="3.0"， 所以 Tomcat 也會去讀 web-fragment.xml ...... 囧>

報告完畢......

ZK-1310 的故事

來寫一篇 ZK-1310 的檢討報告 （誰叫我亂發 issue） 。

起因是這一個 forum thread。 在這裡先 murmur 一下，ZK 截至目前為止是沒有 用 MVVM 寫一個 Tree 的官方範例； MVC 版是有，可是... 只能說那個建立 TreeModel 的 code 實在是太銷魂了， 而且在我修改之前的程式碼根本不能跑。 另外也很好奇，自己從 MVC 版改裝成 MVVM 有那麼難嗎？ 為什麼一堆歪果人在 forum 上頭掱呢？果然付錢用 ZK 跟拿錢用 ZK 差很多 [淚目]

啊啊... 是檢討報告、不是 complain 大會... [逃]