SQLPage v0.17.1 documentation
If you are completely new to SQLPage, you should start by reading the get started tutorial, which will guide you through the process of creating your first SQLPage application.
Building an application with SQLPage is quite simple. To create a new web page, just create a new SQL file. For each SELECT statement that you write, the data it returns will be analyzed and rendered to the user. The two most important concepts in SQLPage are components and parameters.
- components are small user interface elements that you can use to display your data in a certain way.
- top-level parameters are the properties of these components, allowing you to customize their appearance and behavior.
- row-level parameters constitute the data that you want to display in the components.
To select a component and set its top-level properties, you write the following SQL statement:
SELECT 'component_name' AS component, 'my value' AS top_level_parameter_1;
Then, you can set its row-level parameters by writing a second SELECT statement:
SELECT my_column_1 AS row_level_parameter_1, my_column_2 AS row_level_parameter_2 FROM my_table;
This page documents all the components provided by default in SQLPage and their parameters. Use this as a reference when building your SQL application. If at any point you need help, you can ask for it on the SQLPage forum.
If you know some HTML, you can also easily create your own components for your application.
components
The "http_header" component
An advanced component that can be used to create redirections, set a custom caching policy to your pages, or set any HTTP header. If you are a beginner, you probably don't need this component. When used, this component has to be the first component in the page, because once the page is sent to the browser, it is too late to change the headers. Any valid HTTP header can be used as a top-level parameter for this component. HTTP headers are additional pieces of information sent with responses to web requests that provide instructions or metadata about the data being sent — for example, setting cache control directives to control caching behavior or specifying the content type of a response.
Top-level parameters
Access-Control-Allow-Origin
Cache-Control
Content-Disposition
Location
Set-Cookie
Example 1
Set cache control directives for caching behavior. In this example, the response can be cached by the browser and served from the cache for up to 600 seconds (10 minutes) after it is first requested. During that time, even if the cached response becomes stale (outdated), the browser can still use it (stale-while-revalidate) for up to 3600 seconds (1 hour) while it retrieves a fresh copy from the server in the background. If there is an error while trying to retrieve a fresh copy from the server, the browser can continue to serve the stale response for up to 86400 seconds (24 hours) (stale-if-error) instead of showing an error page. This caching behavior helps improve the performance and responsiveness of the website by reducing the number of requests made to the server and allowing the browser to serve content from its cache when appropriate.
select
'http_header' as component,
'public, max-age=600, stale-while-revalidate=3600, stale-if-error=86400' as Cache-Control;
Example 2
Redirect the user to another page. In this example, the user is redirected to a file named another-page.sql at the root of the website. The current page will not be displayed at all. This is useful in particular for content creation pages that contain only INSERT statements, because you can redirect the user to the page that lists the content after it has been created.
select
'http_header' as component,
'/another-page.sql' as Location;