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 ...... 囧>

報告完畢......