Accidental postbacks will also cause much confusion in the debugger, because suddenly the data being looked at will be gone, and will be replaced by new data (much like what would happen in an ASP.NET project without Jaxcent.)
Therefore - unless you are adding Jaxcent in an ad-hoc manner to an existing ASPX project for handling particular event(s) - postbacks should be disabled in Jaxcent.
Submits without an ACTION
do cause PostBacks, and such PostBacks should be disabled by
adding the code
onSubmit="return false;" in all the
FORM tags, e.g.
This should be done on all FORMS being used in Jaxcent. The only exception are FORMS that are being used to upload files. (For uploading files, see the sample project for File Uploading.) In these cases, the SUBMIT action is required to upload the file, and Jaxcent handles this case appropriately (without involving a PostBack.)
<FORM onSubmit="return false;">
All INPUT fields should be placed inside such forms - while Jaxcent doesn't actually need FORMs, some browsers will not show INPUT fields if they are not inside FORM tags.
But it does integrate well with .ASPX files.
It is important to remember that while Jaxcent is aware of .ASPX, the reverse is not
true. In particular, when Jaxcent events are being processed, at that time
the page object has finished its lifecycle as far as as .ASPX is concerned.
Response object can no longer be used to do things like re-direct to
a different page or set session data, or anything which requires the .ASPX to do a post-back.
Instead, these tasks must be done in a Jaxcent way. Instead of
Navigate method from the
JaxcentPage class should be called to cause
the browser to navigate to
a different URL. Cookies should be set using the
instead of via the
Instead of the .ASPX session, Jaxcent provides its own session for maintaining user data across multiple pages, which should be used.
JaxcentPage.SetBatchUpdatesis useful for doing large volumes of output at once. Setting BatchUpdates to true "batches" all updates to the page, i.e. builds them up internally but does not send them out. When all output has been done, BatchUpdates should be set back to false, which will cause all batched output to be sent out. If using this method, a try/catch block should be used to make sure that if any exceptions arise, batch-updates is still set back to false. Otherwise, all future output actions will have no effect. The
ClickMesample project shows an example of batching updates.