- はい、2つの別々のフィールドがここに行く方法です
- 編集に関しては、2つのパネルを使用できます
ItemTemplate
。1つは表示用、もう1つは編集用です。編集パネルの表示はデフォルトでfalseに設定されています。各行には、アイテムのIDが付いた[編集]ボタンがあり、押すと、クリックしたアイテムのIDCommandArgument
でSession変数を設定します。次に、リピーターを再バインドするときに、各アイテムのIDをSessioneditID変数と照合します。それらが一致する場合は、[表示]パネルの可視性をfalseに設定し、[編集]パネルの可視性をtrueに設定します。編集_パネルには2つのボタンがあります。1つは保存用、もう1つはキャンセル用です。ユーザーが[保存]または[編集]をクリックしたら、バックエンド処理を実行し、Session変数をクリアして、リピーターを再バインドします。「ビルトイン」の編集機能を備えたビルトインコントロールがありますが、リピーターを使用して割り当てられたコントロールの方が優れていると思います。
私はこの方法を何度も使用しましたが、うまく機能します。
上記のポイントのいずれかを説明するコードが必要な場合は、お気軽にお問い合わせください。
余談ですが、XMLは少し奇妙に見えます。各URL/IDペアを表す親ノードがないようです。これは見落とし、タイプミスですか、それともここで何かが足りないのでしょうか。
編集:
これは、シナリオでViewStateを利用するための良い方法です。
private enum PageStates
{
None = 0,
View = 1,
Edit = 2
}
/// <summary>
/// The current state of the page
/// </summary>
private PageStates PageState
{
get
{
if (ViewState["PageState"] == null)
ViewState["PageState"] = PageStates.View; //default to view state
return (PageStates)ViewState["PageState"];
}
set
{
ViewState["PageState"] = value;
}
}
ViewStateアクセスをプロパティにカプセル化することにより、変数(Session、DBなど)を格納するメソッドへの変更は、それにアクセスするコードから抽象化されます。