I'm playing with page inheritence but I am currently stumped by postback, on
a page derived from a base class.
In my base page/class I have defined an HTMLForm object. It is instantiated
and added to the base page's control collection during the Init event of the
base page. I expose this form object to any given derived page through a
public property. And this works, more or less; from the derived page, I can
instantiate textboxes, buttons, etc, add them to the form's controll
collection, and then render the whole thing down to the client. On
postback, I can find the value pairs of the form data in the request.form
collection.
Two things that I'm missing out on (and these are my questions)... First is
there an good way to repopulate the controls on a postback- to maintain
viewstate (i.e. textbox text & dropdown selected values, etc) - currently I
perform a somewhat tedious/crude task of scanning the request.forms
collection and manually repopulate everything.
My second question is what I am more interested in, it is about postback
firing events on the server. If, on the derived page, I add a button to my
form object's control collection and reder it, then on postback, it doesn't
appear to raise a click event on the server side. I could simply check
__EVENTTARGET's value if page.ispostback to see what caused postback (and
that's what I'm doing so far), but this isn't the solution I want to use. I
know that it's possible for asp.net to have a button raise a click event
server-side on postback, the eventtarget method is sort of 'primitive' and
I'd like to handle the click event properly. I would like to convert an
existing asp.net website over to the inherited page model, and this website
already relies on server-side click events which I do not want to rewrite to
check eventtarget, etc.
Is this an uncommon approach to site design? I don't find much
documentation regarding these issues.
