SQLPage v0.37.0 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

authentication
Create pages with password-restricted access. When you want to add user authentication to your SQLPage application, you have two main options: 1. The `authentication` component: - lets you manage usernames and passwords yourself - does not require any external service - gives you fine-grained control over - which pages and actions are protected - the look of the login form - the duration of the session - the permissions of each user 2. [**Single sign-on**](/sso) - lets users log in with their existing accounts (like Google, Microsoft, or your organization's own identity provider) - requires setting up an external service (Google, Microsoft, etc.) - frees you from implementing a lot of features like password reset, account creation, user management, etc. This page describes the first option. When used, this component has to be at the top of your page, because once the page has begun being sent to the browser, it is too late to restrict access to it. The authentication component checks if the user has sent the correct password, and if not, redirects them to the URL specified in the link parameter. If you don't want to re-check the password on every page (which is an expensive operation), you can check the password only once and store a session token in your database (see the session example below). You can use the [cookie component](?component=cookie) to set the session token cookie in the client browser, and then check whether the token matches what you stored in subsequent pages.
download
The *download* component lets a page immediately return a file to the visitor. Instead of showing a web page, it sends the file's bytes as the whole response, so it should be used **at the very top of your SQL page** (before the shell or any other page contents). It is an error to use this component after another component that would display content. How it works in simple terms: - You provide the file content using a [data URL](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs). A data URL is just a text string that contains both the file type and the actual data. - Optionally, you provide a "filename" so the browser shows a proper Save As name. If you do not provide a filename, many browsers will try to display the file inline (for example images or JSON), depending on the content type. - You link to the page that uses the download component from another page, using the [button](/components?component=button) component for example. What is a data URL? - It looks like this: `data:[content-type][;base64],DATA` - Examples: - Plain text (URL-encoded): `data:text/plain,Hello%20world` - JSON (URL-encoded): `data:application/json,%7B%22message%22%3A%22Hi%22%7D` - Binary data (Base64): `data:application/octet-stream;base64,SGVsbG8h` Tips: - Use URL encoding when you have textual data. You can use [`sqlpage.url_encode(source_text)`](/functions?function=url_encode) to encode the data. - Use Base64 when you have binary data (images, PDFs, or content that may include special characters). - Use [`sqlpage.read_file_as_data_url(file_path)`](/functions?function=read_file_as_data_url) to read a file from the server and return it as a data URL. > Keep in mind that large files are better served from disk or object storage. Data URLs are best for small to medium files. There is a big performance penalty for loading large files as data URLs, so it is not recommended.