Pages
The functions and macros to work with pages are defined in the
REBLOCKS/PAGE
package.
Page life-cycle
When user opens a new page of the app, init-page
generic-function
get called. It should return or root widget or an object of page
class.
If variable *pages-expire-in*
is not NIL
, then page will be deleted from memory
after this number of seconds. Hovewer, each action call extends expiration time
to *extend-page-expiration-by*
seconds.
A variable *max-pages-per-session*
controls the maximum number of pages in one user
session. Older pages will be expired at the moment, when user tries to open a new page.
These settings are NIL
by default, but may be used to protect server for DoS attacks
where attacker tries to fill all server memory with useless pages.
If you define your own page class, then you can define
page-expire-in
, extend-page-expiration-by
and max-pages-per-session
generic-functions
to control how long page should live.
Page metadata
Any data can be associated with a page. For example, dependencies loaded into the page are saved into the metadata, to avoid assets duplication.
You can get current page using current-page
function and then retrieve metadata with
page-metadata
and change it using (SETF
page-metadata
) or ensure-page-metadata
macro.
Warning, if there are some parallel threads which might change metadata
then you should wrap all changing code in with-metadata-lock
macro.