搞定thinkphp帶參分頁

thinkphp是什么就不用多說了，一個輕量級的PHP MVC框架；前幾天搞搞這個東西，做了個相冊，發現，它的分頁很讓我糾結，特別是帶參分頁。

按照它的手冊來吧，沒多大效果；后來，直接看它的分頁類，也不是很復雜。搞明白了它的原理，只不過就是將$where數組中的參數，分離，以GET的方式，傳遞到分頁類中，然后再將這些參數又組合到查詢語句中，實現帶參分頁。然后，才發現，在$where數組中傳遞的，和表單中的name值要一致，才能這樣做。否則的話，傳遞過來，到了下一頁，是收不到的。

還有一個問題，$where數組中，是可以再有數組的，好比有$p=array('eq',$kid)，這個變量$p再添加到$where中的話，直接按手冊上的來分離參數，似乎也沒效果。解決這個問題時，又寫了個函數，判斷是不是數組，然后再分離，相當于一個遞歸。

還有個問題就是，分頁連接的時候，會自動加上本頁的操作名，就是說，本來是/Index/Pager/的話，分頁后，會變成/Index/Pager/Pager，這也讓我糾結，不知道原因在哪里。

最后呢，還是沒有按照手冊上的方法弄好。想了想，不就是把參數傳遞過去嘛，需要那么糾結嘛。改裝了一下它的show()函數，去掉了URL參數過濾這個功能，直接就是分頁，比如說，頁面是/Index/Pager，那么，使用ushow("/Index/Pager")（改裝后的），得到的就是/Index/Pager/&p=2，很明顯p=2就是第二頁。這個也可以用于不帶參的分頁。實際上，我就是覺得它這個分頁有點糾結，在還沒有寫到帶參分頁的時候，我就改裝了這個函數，正好，這里用上了。然后呢，就是把需要的參數在Action里面組裝一下，傳遞到前臺，到前臺哪里呢，肯定是javascript里面。然后再將這個參數，添加到分頁后的<a>標簽里面；部分代碼：

$show = $Page->ushow(__URL__."/".$_REQUEST[C(VAR_ACTION)]."/");（調用組裝后的分頁函數，實際上，就是將它封裝好的，又打開，自己處理。）

$output="/KID/".$kid."/spbegintime/".$p["spbegintime"]."/spendtime/".$p["spendtime"]."/spname/".$p["spname"];（Action里面，組裝分頁參數；也可以用&來區分參數。）

$this->assign('outpager',$output);綁定頁面變量。

$("#pager a").click(function(){
var i=$("#pager a").index(this);
$("#pager a").eq(i).attr("href",$("#pager a").eq(i).attr("href")+"{$outpager}");
});前臺修改連接地址，將參數加進來。

最近TP出2.1了，還沒去看，嘿嘿。感覺吧，有時候用這樣的框架，會不習慣，似乎就是少了一種感覺。用JQ也一樣，有時候就習慣性的$("form").submit();而其實頁面中就一兩處用到了JS，都沒把JQ加載進來；我都在想，會不會使用JQ，讓我把普通JS給忘了？這也許就是JQ的目標之一吧，哈哈。當然，作為開發者的話，不能只局限于一個框架，一種語言。

最近上班改ccmall.cn也糾結，常常就是本地改好了，上傳到服務器上，就沒用了；沒辦法，服務器我沒權限修改，我得將改好的往上傳，上面的人再修改服務器上的?？?。。

有時候在想，像ccmall.cn這樣的大型B2B，B2C網站，做成功了，每天至少是要經受上萬IP，數十萬次PV的，像這樣一個課題，弄到實際運用中去，會不會有問題？畢竟大學里面的課題和實際運用的項目，差距是非常大的。還有，項目中，將大量的，本來最基本的html標簽，封裝成那么復雜的服務端控件，生成大量的ViewState，然后修改的時候，就N麻煩。有必要么？在修改的過程中，經常就發現，有時候，花大力氣寫的一個服務端控件，就一個地方用到了，要實現的功能，完全可以幾句很基本的JS和簡單的HTML標簽搞定。咳。。

看了看一些PHP項目，覺得還是那種簡單明了，簡潔，不臃腫。。微軟就喜歡把別人當傻瓜，什么都封裝好。（這里僅僅指asp.net）。當然了，也不是說asp.net一無是處哈，只是覺得，好多人都沒有正確的運用asp.net就是。其實，.net的強類型，編譯型，以及泛型，Ado.net等都是非常不錯的，還有后來推出的asp.net MVC，包括.net3.0之后推出來的一些新特性，像SQL CLR，這樣重邏輯的數據庫操作，還是挺實用的。