Pages are top-most controls that have no parent. The presentation of pages are directly displayed to end-users. Users access pages by sending page service requests.
Each page can have a template file. The file name suffix must be .page. The file name (without suffix) is the page name. PRADO will try to locate a page class file under the directory containing the page template file. Such a page class file must have the same file name (suffixed with .php) as the template file. If the class file is not found, the page will take class TPage.
A form submission is called postback if the submission is made to the page containing the form. Postback can be considered an event happened on the client side, raised by the user. PRADO will try to identify which control on the server side is responsible for a postback event. If one is determined, for example, a TButton, we call it the postback event sender which will translate the postback event into some specific server-side event (e.g. OnClick and OnCommand events for TButton).
TPage has a IsPostBack property exposing whether the current request being handled is the first request for this page or the consequence of a postback.
A callback is a special form submission that, instead of requiring a full page reload on the browser, gets executed in the background through an ajax call. So, a callback is considered a postback too, but not vice versa.
A callback is handled as a normal postback but, instead of re-rendering the entire page, only the specific changes occured on the page gets sent back to the client and merged with the current browser page. A typical callback response consists of:
Understanding the page lifecycles is crucial to grasp PRADO programming. Page lifecycles refer to the state transitions of a page when serving this page to end-users. They can be depicted in the following statechart,