0

AJAXを多用するWicketアプリケーションを作成しており、を介してCSSに貢献しているパネルがありますrenderHead()。ただし、パネルがAJAXを介して（たとえば、を介して）置き換えられている場合AjaxTabbedPanel、古いパネルのヘッ​​ダーの寄与は残り、アプリケーションの残りの部分を汚染します。応答の肥大化とは別に、これはCSS宣言が過度に一般的である場合に問題を引き起こし、その結果、アプリケーションの他の領域でレンダリングの問題が発生します。

これを回避する方法はありますか？IHeaderReponseたとえば、パネルが交換されたとき/表示されなくなったときに再作成するメカニズムはありますか？

価値のあるものとして、ヘッダー寄稿者の例は次のとおりです。

@Override
public void renderHead(IHeaderResponse response) {
    response.renderCSSReference(new SharedResourceReference(SearchMainPanel.class, "Search.css"));
}

Wicket1.5.3を使用しています。

<link rel="stylesheet" ... />パネルのマークアップにをレンダリングする<body>（つまり、ヘッダーコントリビューターを使用しない）カスタムラベルで成功しましたが、IE8はこのCSSの存在を認めることを拒否します。したがって、戦略を再考する必要があります。

4

1 に答える 1

2

各AjaxRequestTargetは、その要求専用の新しいIHeaderResponseを受け取ります。あなたが見ている問題は、前のリクエストがそのページに存在したくないスタイルシートで応答したという事実によるものです。ページ上にすでにレンダリングされているスタイルシートをブラウザに無視させる唯一の方法は、そのファイルなしでページを再レンダリングすることです。

この場合、各タブをレンダリングするときに初めてスタイルのカスケードに依存することができます。これは、そのパネルをレンダリングするときにWicketが関連するスタイルシートをロードするためです。ただし、以前にレンダリングされたタブ（パネル）に戻ると、Wicketはすでにロードされているため、スタイルシートを再レンダリングしません。これは、カスケードスタイルの制限を克服する方法が必要であることを意味します。

これを行う最良の方法は、スタイルに名前空間を付けることです...つまり、各パネルを名前空間クラス（ "tab1"などのよりコンテキスト的に正確なもの）のタグでラップする必要があります。その後、すべてのスタイルをそのクラスに基づいて作成します。

.tab1 .heading {
    font-weight: bold;
}

.tab1 .description {
    background: blue;
}

.tab2 .heading {
    font-size: 1.3em;
}

.tab2 .description {
    background: lightblue;
}

これにより、各タブの個々のスタイルを区別できるようになり、名前空間付きセレクターでも必要なカスケードが機能するようになります。

于 2012-06-15T18:14:52.790 に答える