SQLPage Documentation (original) (raw)

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.

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.

authenticationCreate 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** - 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 to set the session token cookie in the client browser, and then check whether the token matches what you stored in subsequent pages.

form# Building forms in SQL So, you have an SQL database, and would like to let users input data into it? The `form` component is what you are looking for. ## Collecting data from users to your database The form component will display a series of input fields of various types, that can be filled in by the user. When the user submits the form, the data is posted to an SQL file specified in the `action` property. ## Handle Data with SQL User-entered data is posted to an SQL file, that will handle the data, and will be able to insert it into the database, search for it, format it, etc. For example, a value in a field named "x" can be referenced as `:x` in the SQL query of the target page. ## Examples - **Data Entry Automation**: Forms for tasks like inventory management. - **Custom Report Builder**: Generate reports based on user-specified criteria. - **Database Management**: Update records or query data. - **Admin Panel**: Manage user roles and permissions. - **Data Analytics with SQL**: Collect data for analytics. - **SQL Query Parametrization**: Build and execute complex SQL queries that depend on user input. - **SQL CRUD Operations**: Perform Create, Read, Update, and Delete operations. - **Web SQL**: Integrate forms into web applications.

http_headerAn advanced component to set arbitrary HTTP headers: can be used to set a custom caching policy to your pages, or implement custom redirections, for example. 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. 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. Any valid HTTP header name can be used as a top-level parameter for this component. The examples shown here are just that, examples; and you can create any custom header if needed simply by declaring it. If your header's name contains a dash or any other special character, you will have to use your database's quoting mechanism to declare it. In standard SQL, you can use double quotes to quote identifiers (like "X-My-Header"), in Microsoft SQL Server, you can use square brackets (like [X-My-Header]).

status_codeSets the HTTP response code for the current page. This is an advanced technical component. You typically need it when building internet-facing APIs and websites, but you may not need it for simple internal applications. - Indicating operation results when using SQLPage as an API - `200`: *OK*, for successful operations - `201`: *Created*, for successful record insertion - `404`: *Not Found*, for missing resources - `500`: *Internal Server Error*, for failed operations - Handling data validation errors - `400`: *Bad Request*, for invalid data - Enforcing access controls - `403`: *Forbidden*, for unauthorized access - `401`: *Unauthorized*, for unauthenticated access - Tracking system health - `500`: *Internal Server Error*, for failed operations For search engine optimization: - Use `404` for deleted content to remove outdated URLs from search engines - For redirection from one page to another, use - `301` (moved permanently), or - `302` (moved temporarily) - Use `503` during maintenance