jCTの葛藤、フロントテンプレートの下のデザインモードVSコンポーネント、汎用コンポーネントgone
6362 ワード
ずっとjCTでWEBビジュアルを書こうと思っていたので、Gridから作ろうと思っていましたが、実際に私がやっていたときにこんな葛藤に気づきました
jCTはもともとテンプレート技術であり,コンポーネントは特定のテンプレート技術と考えられる(ただしjavascriptコードにテンプレートが書かれているだけである)
テンプレートに現れるhtmlの元のコード形式、改造拡張、構造調整、属性の増加は従来のコンポーネントに比べて非常に便利であるため、コンポーネントを作りたいという考えもおかしくない.
しかし、この柔軟性こそjCTという方向を破壊した.汎用コンポーネントのテンプレートコードは柔軟性を完全に体現できず、複雑になりやすいからだ.
ただでさえ直接htmlテンプレートを书くのは简単ですから、判断したり、ループをつけたり、ページを分けたりするのは简単です.
コードトーク:コメント用
table部
<!---///grid recorders-->
<!--grid ，recorders -->
<table>
<thead>
<!-- ， th ， class -->
<tr>
<th> </th>
<th> </th>
<th> </th>
</tr>
</thead>
<tbody>
<!---this.Fn.V.push(this.rows.GetView(recorders));-->
<!-- ， jCT push ，
grid rows ， ， this.rows.GetView(recorders) push
tbody ， ， recorders
-->
<!---///rows recorders-->
<!---for(var i=0;i<recorders.length;i++){var l=recorders[i];-->
<!-- ， ， ？ -->
<tr name="/" value="user.get" class="submitdblc">
<td name="id" value="+-l.id-+"><span name="user">+-l.user-+</span></td>
<!-- id ， ， name="/" -->
<td name="xingming">+-l.xingming-+</td>
<td name="zhiwei">+-l.zhiwei-+</td>
</tr>
<!---}-->
<!---///rows-->
</tbody>
</table>
<div>
<!---this.Fn.V.push(page.GetView(toPages(recorders)));-->
<!-- ,toPages ， -->
</div>
<!---///grid-->
<!-- ， -->
<!---///page p-->
<div class="page">
<fieldset>
<!---for(var i=p.start;i<=p.end;i++){-->
<button class="pageButton" value="+-i-+">+-i-+</button>
<!---}-->
<button class="pageButton" value="+-p.prev-+"> 9 </button>
<button class="pageButton" value="+-p.next-+"> 9 </button>
<button class="pageButton" value="+-p.count-+"> +-p.count-+ +-p.rows-+ </button>
</fieldset>
</div>
<!---///page-->
ページ分けの関数は、上のコードにバックグラウンドで返されるrecordersオブジェクトに直接関連パラメータが含まれていることを要求します.もちろん、これらのパラメータを独立させることができます.
/*
*sets ，
* page_count ， js , ，
* , ，
* page_no
* rows_count
*range ， 9，
* ，
*page ,
* start:
* end:
* prev: range
* next: range
* no:
* rows:rows_count
*/
function toPages (sets,range){
range=range||9;
var rng=Math.floor(range/2);
var page={start:0,end:0,prev:0,next:0};
page.count= sets.page_count|| 0;
page.no = sets.page_no || 0;
page.rows=sets.rows_count||0;
if(!page.no) return page;
page.start=page.no-rng;
if(page.start<1) page.start=1;
page.end=page.no+rng;
if(page.end>page.count) page.end=page.count;
page.prev=page.start-rng;
if(page.prev<1) page.prev=1;
page.next=page.end+rng;
if(page.next>page.count) page.next=page.count;
return page;
}では、この中にどれだけの成分がアセンブリ化できますか?これらの面があると思いますが、問題と疑問は同時に存在します.
<td name="zhiwei" value="+-l.zhiwei-+">+-dict.zhiwei[l.zhiwei]-+</td>$('table.dbleditbox tr').live('dblclick',yourfunc);
<tr name="/" value="user.get" class="submitdblc">この問題はついに肝心な点を見つけて、コンポーネントVS設計モード、私達の既知のコンポーネントは確かに自分の設計モードを縛って、開発者に対して確かに多くの制限があって、フロントテンプレートは確かに開発者に自由を与えて、しかし同時に開発者が自分の1本の道を模索して、やっと通行することができます.jCTの葛藤:複雑な応用に対して、開発者は自分の設計モードがあってこそ「飛躍的に向上する」ことができる.複雑な応用用コンポーネントの需要がもっと大きいため、コンポーネントを細かく研究するか、設計モードから着手するか、自分のコードを書くか、難しい選択である.
確定できるのはフロントテンプレート+設計モードのコード量で、柔軟性はすべて純粋なコンポーネントよりはるかに優れて、フロントテンプレートの下で応用需要によって設計テンプレートを分類して、制定した“コンポーネント”を形成して、自分で直ちに書くコンポーネントで、jCTがコンパイル型テンプレートであることを忘れないでください、最後の実行コードは独立して独立したjsに保存できる(このようなエクスポート方法を書くべきだと思います)、ページングバーは独立してコンポーネントになるようで、このような小さなコンポーネントは、直接テンプレートをコピーして貼るほうが便利だと思います.