Pages

The functions and macros to work with pages are defined in the REBLOCKS/PAGE package.

Page life-cycle

When a user opens a new page of the app, the init-page generic function gets called. It should return a root widget or an object of the page class.

If the variable *pages-expire-in* is not NIL, then the page will be deleted from memory after this number of seconds. However, each action call extends the expiration time to *extend-page-expiration-by* seconds.

The variable *max-pages-per-session* controls the maximum number of pages in one user session. Older pages will be expired at the moment when a user tries to open a new page.

These settings are NIL by default, but may be used to protect the server from DoS attacks where an attacker tries to fill all server memory with useless pages.

If you define your own page class, you can define page-expire-in, extend-page-expiration-by and max-pages-per-session generic functions to control how long the 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 asset duplication.

You can get the current page using the current-page function and then retrieve metadata with page-metadata and change it using (SETF page-metadata) or the ensure-page-metadata macro. Warning: if there are parallel threads which might change metadata, then you should wrap all changing code in the with-metadata-lock macro.