Button AutoPostBack to "false"

[geoffrey.mcgill]

I need some feedback...

For a while now I've been thinking of changing the default value of the the <ext:Button> .AutoPostBack property from "true" to "false".


Currently, the default AutoPostBack value is "true". If you click on the Button in a browser, the button will postback to the server. This currently reproduces the functionality of the <asp:Button>.


We want to strongly encourage using either the <Listeners> or <AjaxEvents> to handle the button "click" events. If an AutoPostBack is required with the <ext:Button>, the property would have to be explicitly set, similar to how all the other <asp> controls which support auto posting back to the server.


Again, the revision would involve changing the default value of the <ext:Button> .AutoPostBack property from "true" to "false".


Let me know what you think.

[Timothy]

Hello Geoffrey,

Great topic!

I think with the recent introduction of the AjaxEvents and their new capabilities, this really eliminates the need for the traditional post back. I would totally support changing AutoPostBack to default to "false".

Furthermore, I believe Ext:Button is the only control that explicitly has AutoPostBack enabled ;)

Cheers,
Timothy

[jchau]

I agree that AutoPostback should be set to False. If Coolite can throw an exception everytime a regular postback occurs, that would be even sweeter! Just kidding. But seriously, postbacks are obsolete and should be discouraged.

[amitpareek]

I agree, Autopostback to false would be good. I dont see any reason to keep them, when we have AjaxEvents working so well.

With that I think even the default handler parameter will be changed to AjaxEventArgs?

Thanks

[geoffrey.mcgill]

In Visual Studio design-mode, double-clicking on the <ext:Button> would continue to wire up the default server event handler using the classic EventArgs. Only now, the developer would also have to manualy set the .AutoPostBack property to "true", just as they would if wiring up an event to the <asp:TextBox> control.

There's a lot more functionality built into the <AjaxEvents> and AjaxEventArgs, such as <UserParms> collection, but we can not add UserParams to EventArgs and I would rather not change the default "OnClick" event signature. The only change would be the default value of .AutoPostBack.

If a developer decides to use classic PostBacks (UpdatePanel), I don't want to move too far off the path from what they expect to happen. Currently, switching from an <asp:Button> to an <ext:Button> only involves changing the TagPrefix. With v0.6, they (may?) now also have to set .AutoPostBack="true".

[amitpareek]

Hmm... I just thought it will make things even more simpler..

But you are right, there would be many people still using the update panel...

[Timothy]

Geoffrey,

Here is a quick thought; only set it to False when an OnClick event is not provided ;)

Cheers,
Timothy

[geoffrey.mcgill]

Timothy (9/17/2008)
Here is a quick thought; only set it to False when an OnClick event is not provided ;)

Ya, we talked about that as well, but I don't think I'm going to go there. I really don't want to mess with automatically setting native asp.net webcontrol properties on someones behalf. There's a few spots where we do this in the Toolkit, but it's with Toolkit specific properties.

If the property is native asp.net functionality, then I'm just happy following the native behaviour... which, is let the developer set the property manually.

Thanks for the feedback.

[amitpareek]

That could cause a problem in some scenarios.

Many a times when you double click the button in the design view, it does'nt add OnClick Event in the design code. Rather It creates a handler with handles Button1.Click in the end.

Thanks,

[Timothy]

I'm not going to lose any sleep over having to set it manually ;)

Cheers,
Timothy