How do I convert an existing usercontrol to a Kentico Web Part? - webforms

Question

I have an existing usercontrol "BigForm.ascx":
<%# Control
Language="C#" AutoEventWireup="true"
CodeFile="BigForm.ascx.cs" Inherits="BigForm" %>
<asp:Panel runat="server" DefaultButton="btnSubmit">
<%--SUPER COMPLICATED FORM--%>
<asp:Button ID="btnSubmit" runat="server" Text="Submit" OnClick="btnSubmit_Click" />
</asp:Panel>
BigForm.ascx is very complicated - it dynamically adds subcontrols to placeholders, it encapsulates a whole lot of business logic, the markup is heavily customized, etc.
I can add BigForm.ascx to Kentico using the "User Control" web part and it works perfectly.
But if I convert BigForm.ascx to a "proper" web part - by inheriting from CMSAbstractWebPart instead of from UserControl - postbacks don't fire. I'll click on the submit button and nothing happens.
I've seen the Kentico doco on designing forms using the form builder, but this usercontrol already works perfectly, and I suspect that it's far too complicated to build with a WYSIWIG. Not to mention that I strongly prefer building forms using Visual Studio.
My understanding is that using a web part is the "correct" thing to do with Kentico, and that doing so will let users specify properties on that Web Part (e.g. if we'd like to translate the form in future - we could put a "First Name label text" on the web part and the user could put in "Vorname" instead of "First name").
What do I need to do to convert a working usercontrol into a Kentico web part?

Answer 1

First off, if it's not broke then don't fix it, unless you're looking or required to have more diversity in your control. If your complex control works well using the User Control web part AND you're not up for using Kentico's out of the box functionality, then I'd suggest sticking with the User Control web part, because it works.
If you are interested in learning more about how to create web parts, how their life cycle differs from a standard user control and making your control more dynamic, then read this documentation.
One of the big differences you'll notice is the Page_Load event is there but isn't used much. The OnContentLoaded event is used, which happens before the standard asp.net OnInit event. This is where you set all your property values and load your data. Button events do happen just like within standard Forms, after the Page_Load event. Just like standard asp.net, any dynamically loaded controls need to be reloaded/created on every post back. Controls which are holding data need to be bound on each post back as well. This doesn't mean you have to retrieve the data again because the caching engine is awesome, it means the control has to have a DataSet assigned to it and not conditionally loaded. Take a look at this example on how to load cached data in Kentico.
Regarding building forms, yes it works well within Visual Studio, no disagreements there, although when you have to create and handle all your CRUD actions manually vs. simply catching those events, either within your web part or globally, it makes it much easier, more dynamic, more robust and faster to build.
As a long time Kentico developer, it does take a bit to get out of the mindset that you need to develop everything from the ground up. In many cases the tool you're using, Kentico in this instance, already have standard controls created for what you're doing or needing to do. OR if you have a complex solution, breaking it down into smaller pieces and create smaller user controls and dynamically load those into your web part works very well.
Good luck with your endeavors!
Form documentation
Working with Form Data using API