我處理過,其需要到同一塊的用戶輸入的響應的多個用戶控件。
我創建了一個從System.Web.UI.Page繼承的基頁。我將用戶輸入作爲一個屬性包含在這裏(稍後會詳細介紹)。
我定義這個接口
public interface IRespondToInput
{
int InputID
{
get;
set;
}
}
好吧,這不叫那正是,但每次我想看到實施的更改的用戶控件。該接口由一個屬性組成,該屬性反映了基本頁面中的屬性。
public int InputID
{
get
{
return _inputID
}
set
{
_inputID = value;
SetInputs(this, _inputID);
}
}
在基本頁面方法的制定者,我稱之爲一個例程遞歸通過控制層次跳躍,尋找實現IRespondToInput什麼,只要設置一個用戶控制該接口匹配的被發現的財產。 (見代碼)
protected void SetInputs(Control theControl, int theInputID)
{
if (theControl.Controls.Count > 0)
{
foreach (Control mySubControl in theControl.Controls)
{
if (mySubControl is UserControl || mySubControl is System.Web.UI.HtmlControls.HtmlForm)
{
if (mySubControl is IRespondToInput)
{
((IRespondToInput)mySubControl).InputID = theInputID;
}
SetInputs(mySubControl, theInputID);
}
}
}
}
這反過來會觸發用戶控件上的本地綁定事件。
事實上,我可以從繼承的頁面調用屬性。
例如(在後面的用戶控件代碼)
int mySetting = ((MyBasePage)Page).InputID;
我只是想砸兼容控制到兼容的頁面,讓他們的工作。這種方法可能適用於你。
增加了對原始的海報
如果你想避免把這個邏輯在派生基本頁面,爲什麼不創建一個單獨的用戶控件(d - 繼續你的例子),它封裝了您的切換邏輯,但也發現所有控件實現了IRespondToInput接口?
在這個用戶控件,您的二傳手看起來像: -
public int InputID
{
get
{
return _inputID
}
set
{
_inputID = value;
SetInputs(Page, _inputID);
}
}
將這一控制用戶控件爲A,B和C
這樣的子控件,您不必使每個頁面ADerivedPage - 您可以將您的UserControls放到您需要它們的頁面上。並且您將順利通過Page
作爲參數,因爲它從Control
繼承。
用戶體驗與小部件或小工具類似。由用戶獨立管理,但可以選擇更新其他小部件/小工具以匹配此設置。 – 2009-10-13 10:06:50
然後這本書是給你的。這是關於一個可定製的基於窗口小部件的用戶門戶。 – 2009-10-13 10:19:44
+1:自從眼鏡蛇書以來最令人毛骨悚然的O'Reilly動物。 – Juliet 2009-10-14 15:06:19