The FirstSpirit™ FormEdit module consists of an editorial component for the creation of web forms using the FirstSpirit SiteArchitect or ContentCreator and a web component in the form of a servlet, which accepts and processes data entered by the user.
The following forms of processing of form data are supported:
Further, it is possible to evaluate the forms via your own implementations. The processing methods named above can also be combined with each other.
The following graphic shows the module’s layout and how it functions using the example of the live server. The web and application servers used in FirstSpirit are used for use of the module within the preview or staging.
The FormEdit module has the following technical requirements:
FirstSpirit™ FormEdit is installed in three steps:
Use the fsm file supplied to add the module on the FirstSpirit server.
To install the module, open the ServerManager
and select →
.
The main panel contains a list of modules installed on the FirstSpirit server.
After clicking All permissions
(see figure Module management in the server properties).
The project application FS FormEdit ProjectConfiguration
, the web application FS FormEdit
, and the library FS FormEdit Scripts
are parts of the FirstSpirit™ FormEdit module.
The Project Application provides media, page, section, script and table templates which can be used to design forms.
The component is Visible for the Project
area.
It is therefore a project locale component.
This can be added following installation of the project component within the required projects.
The web application provides servlets, which can be used and called within the project.
The component is Viewable for the →
areas.
It is therefore a web locale component.
This can be added to the different web areas (preview
, staging
, live
, ContentCreator
) within the required projects following installation.
The library provides the classes that are used from within the provided scripts.
After any module installation or update, the FirstSpirit server needs to be restarted. |
A project-specific configuration is required in order to use the FirstSpirit™ FormEdit module.
It is set up using the project component, which must be added to the project being used.
To add the project component, open the ServerManager
and select →
.
A list of all existing project components is displayed in the main panel.
Click FS FormEdit ProjectConfiguration
and click to confirm your selection.
The project component is then added to the list in the main panel and will need to be configured (see figure Project components in the project properties).
To configure the project component, select the entry in the list and click to open the associated dialog (see figure Configuration dialog for the project component).
Select a database layer from the Schema combobox and click .
The selection list contains all database layers approved for the project.
If you have not used any layers to date, or if you want to use your own database for the module, select New layer
.
If this option is selected, a new layer is generated, which points to FirstSpirit’s internal Derby database.
For further information on database layers, please refer to the FirstSpirit Manual for Administrators.
After you have clicked the button and close the dialog, it is not possible to make any more changes to the configuration. Renewed importing is only possible by means of and renewed of the project component. |
A web component needs to be added in addition to the project component.
To add a web component, open the ServerManager
and select →
.
Inside the main panel, four tabs are visible.
Each tab contains a list of the existing web components.
For each tab, click FS FormEdit
, and click to confirm.
Then install and activate the web component on an active web server.
The server can be selected using the selection box.
The web component is then added to the list in the main panel for all four tab pages.
After adding them to a web area, it is possible to configure the components; either with the web.xml generated by the component or a generic GUI (see figure Configuring the web application).
Different parameters are available for configuring:
redirect:
or forward:
prefix.
forward:ok.jsp
, for example, would generate forwarding with all parameters to the page ok.jsp.
If neither forward:
nor redirect:
is given, redirect always takes place.
redirect:
or forward:
prefix.
forward:error.jsp
, for example, would generate forwarding with all parameters to the page error.jsp.
If neither forward:
nor redirect:
is given, redirect always takes place.
UTF-8
or ISO-8859-1
.
Always ensure that the encoding chosen matches the encoding used in the generated pages (MetaTags or encoding of the language in the |
The path to the configuration file fs-formlogger.ini must be given in this field. If this field is empty, or if the file cannot be found, an empty configuration file is used.
Staging example
2708/de/conf/fs-formlogger.ini
The schedule ID – here 2708
– is placed in front of the path for the staging environment.
Live example
de/conf/fs-formlogger.ini
The path to be given here can also be given as an absolute value.
This example searches for the file relative to the WebAppRoot.
100
.
100
.
6
.
For easier error analysis the FirstSpirit™ FormEdit module can log some information to an appropriate logfile.
This logging uses the log4j2 framework.
Therefore it is necessary to configure log4j2 for your webapplication accordingly, in case this wasn’t done before.
Configuring log4j2 happens by putting the log4j2 configuration file log4j2.properties into the →
directory.
In case this directory doesn’t exist, it can be added manually.
An exemplary log4j2 configuration file could look in the following way:
status = error dest = err name = PropertiesConfig property.filename = target/rolling/rollingtest.log filter.threshold.type = ThresholdFilter filter.threshold.level = debug appender.console.type = Console appender.console.name = STDOUT appender.console.layout.type = PatternLayout appender.console.layout.pattern = %m%n appender.console.filter.threshold.type = ThresholdFilter appender.console.filter.threshold.level = error appender.rolling.type = RollingFile appender.rolling.name = RollingFile appender.rolling.fileName = ${filename} appender.rolling.filePattern = target/rolling2/test1-%d{MM-dd-yy-HH-mm-ss}-%i.log.gz appender.rolling.layout.type = PatternLayout appender.rolling.layout.pattern = %d %p %C{1.} [%t] %m%n appender.rolling.policies.type = Policies appender.rolling.policies.time.type = TimeBasedTriggeringPolicy appender.rolling.policies.time.interval = 2 appender.rolling.policies.time.modulate = true appender.rolling.policies.size.type = SizeBasedTriggeringPolicy appender.rolling.policies.size.size=100MB appender.rolling.strategy.type = DefaultRolloverStrategy appender.rolling.strategy.max = 5 logger.rolling.name = de.espirit.firstspirit.opt.formedit logger.rolling.level = debug logger.rolling.additivity = false logger.rolling.appenderRef.rolling.ref = RollingFile rootLogger.level = info rootLogger.appenderRef.stdout.ref = STDOUT
Please consider that depending on the configuration the logfile may also contain information from other modules. |
For this section, it is assumed that the reader is familiar with handling FirstSpirit Data sources
(content).
The various process options of the form data are configured in the project by so-called loggers.
Each logger is assigned a specific processing type (e.g. MailLogger
) and appropriate parameters.
The various loggers are maintained as data sets (content store data) in a data source (content).
The logger configuration file fs-formlogger.ini is generated on the basis of the logger configuration.
The content schema and table templates necessary for this are generated on installation of the project component.
To create loggers, it is now only necessary to create content for the table template form_edit.formLogger.
For information on the logger types and their configuration options, please refer to Chapter Logger configuration of the processing.
Please ensure you set mapping for the missing languages within the table template form_edit.formLogger. (On delivery, only German is mapped.) Additional columns with _<language abbreviation> should be created for the language-dependent formLogger_description column. |
Open the project in SiteArchitect. There are now two options for creating or editing the logger:
directly via the content (content: FormLogger) in the Content Store
from the form-start section
Clicking the formstart section to open the following form:
button in the content view or in the input component within theAll logger-specific data is entered in this form:
The logger type is required for creating the logger configuration file fs-formlogger.ini. The following logger types are available:
The logger-specific configuration parameters can be specified here. You can choose between three templates for an entry:
logger-template-ref
This template is chosen if a mail template is to be selected from the structure for the MailLogger or MailUploadLogger.
The parameters which can be used here are explained in the following subchapter.
Each logger is assigned a specific processing type (e.g. MailLogger
) and appropriate parameters.
The various loggers are maintained as data sets (content store data) in a data source (content).
The logger configuration file fs-formlogger.ini is generated on the basis of the logger configuration.
Configuring log file processing
de.espirit.firstspirit.opt.formedit.ConsoleLogger
Configuring CSV processing
de.espirit.firstspirit.opt.formedit.CSVLogger
UTF-8
Configuring database processing
de.espirit.firstspirit.opt.formedit.JdbcLogger
org.gjt.mm.mysql.Driver
jdbc:mysql://localhost:3306/logging
It is possible to define into which table column each form parameter is to be added.
If the parameters are not explicitly assigned, the software tries to use the parameter name as the column name.
If this also fails, an entry is only made in the unmappedColumn
(see below, Item Additional parameters).
The following schema applies here:
The value of the form element address1 is to be written in the database, in the street field.
The following special rules can be specified in addition to the mapping rules:
Configuring e-mail processing
output of the form data in the form of an (configurable by means of a file) e-mail (optionally with file attachment too)
The e-mail logger is used to send the form data by e-mail. A separate e-mail is sent for each form. The format and/or text of the e-mail can be configured in a (separate) file. Due to the form-specific logger configuration, if necessary, an e-mail configuration file can be assigned to each form.
de.espirit.firstspirit.opt.formedit.MailLogger
or de.espirit.firstspirit.opt.formedit.MailUploadLogger
true
, if the smtp server requires authentication (smtpAuth)
logger-template-ref
should be selected here as the template.
This can be used to select the template from the structure.
smtpAuth
parameter is set with the value true
, these parameters are mandatory parameters and must be given.
logger-text-password
can be selected here as the template, to display the data concealed.
Configuring URL processing
URL call with parameter passed to another page
The URL logger is used to call another page (URL) with the option of passing on defined parameters of the form. However, the user does not call this page in their browner. A classic application case is, for example, tracking.
de.espirit.firstspirit.opt.formedit.URLLogger
true
/false
)
http://myserver.com/tracking.jsp
)
url.param.<bezeichner>: Unique identifier of the form component
Similar to the JdbcLogger, it is necessary to map the form’s parameters to new parameters. In the case of URLLogger, only the parameters specified in the configuration are attached to the UrlPrefix. If no parameters are configured, each parameter of the form will be attached to the UrlPrefix. |
The e-mail to be sent is configured using the page template mailtemplate. The interface is similar to that of an e-mail program.
;
).
%parameter%
(here: %e-mail%
) to access a form element which contains a valid e-mail address.
If a value is given here, the sender
value given in the logger configuration is overwritten.
Here you can configure the file attachments.
This can be done on the one hand, using %parameter%
or using %all%
.
parameter
is attached to the e-mail.
Several files must be separated by commas (,
).
Example: %datasheet%
,%photo%
After the information required for the e-mail header has been give, the e-mail text is entered.
This text can contain wildcards in the form %name%
, which are used to access values from the form.
The following parameters are available:
%unmapped%
list of all form unedited parameters as CSV (see below)
In addition to these parameters, each form parameter can be used.
This is done using the % notation and the parameter name: %parameter%
Form data which has been sent, but was not output in the mail template via % notation, can be output using the parameter %unmapped%
.
Please note that umlauts may be used within the domain of an e-mail address but that they are forbidden within its username. |
By using this FS_LIST within a page of type mailtemplate
the editor can select files that shall be attached to the email automatically.
E.g. if you would like to send a registration confirmation including your terms of use, you would select the appropriate file in this FS_LIST.
To define the folder that contains the files you would like to send, you have to modify the link template of the FS_LIST elements. The folder can be specified within the FOLDER Tag of the FS_REFERENCE element. E.g. <FOLDER name=”root” …/> will allow to select files from the whole mediastore.
In addition the following variables have to be defined under →
as text fields (CMS_INPUT_TEXT).
These variables are used within the html channel of the link template.
ps_webappContentPath
.
This page template is a functional example template. It is also possible to check data against a database or similar.
This file is not generally valid and must be adjusted for each specific project, if the source is not an XML file. For further information please refer to Chapter Auto Completion Concept. |
This page template is used to process an input source such as XML. If the user makes an entry in an autocomplete form field, the source given on this page is browsed through and the results are shown to the user.
This configuration file contains all the information of your forms or assignment to the processing configurations and these configurations themselves. The content of this file is generically generated by FirstSpirit during generation.
In order for this file to be correctly generated, a page based on the logger-ini-file template must be created in the Page Store,
and the object ID of the form start template, or the templates generated by you which fulfil the function of the form start template, must be entered on this page.
The ID is displayed with the keyboard shortcut ALT + P
in the selected section template
When referencing in the structure, note that the file is filed in the place given when configuring the web component.
Further, the file name of the page must be correctly set in the Site Store.
The name fs-formlogger
is used within this document:
Furthermore the configurations of the FormEdit-Forms that were created in the project are store in the fs-formlogger.ini, so that they can be read from the webserver. This leads to the fact that the webapplication needs to be restarted, as soon as there are changes in the configuration of a form (form_start section) and the deployment was successful. The servlet will then be able to read the changed configuration.
A specific section template order must be adhered to when creating the form to ensure the form works. The section template form-start always marks the start and the section template form-end always marks the end of a form. Any number of sections of the type form-block and form-divider can occur between these two sections.
A form-block element can contain any number of form elements.
The section templates of the form editor provide all the form elements available in HTML and also provide sufficient options for configuring the components. It is necessary to adjust to specific design requirements first before using the components. On the one hand, this can be done by direct adjustment of the HTML code in the section templates and/or by defining cascading style sheets in the integrated stylesheet file. Each form component can be individually assigned a stylesheet class.
The section template form-start introduces a new form. The basic configurations, which solely concern this form, can be made here.
Unique identifier for the form (name
attribute of the form
element)
This identifier may not contain any spaces or special characters/symbols, as the form name is used as part of the servlet call. |
POST
Any number of form elements can be created within a form-block element. The order of the components is irrelevant for the form’s ability to function. Each component can be individually configured. For example, stylesheet classes can be used and the display width and height of the form defined. For precise information and configuration examples, please refer to Chapter Available form elements.
The form-divider element generates a graphic separation within the form and otherwise has no function.
The form-end section template defines the end of the form.
The form editor enables the editor to use the complete set of HTML form elements. As already mentioned, before using the components it is advisable to make an adjustment to the HTML source code together with the stylesheet file. In this way, individual design templates can be adhered to and are available on the whole of the web page. However, the HTML tags of the form elements should not be affected by the changes, to ensure correct function of the JavaScript checks.
The form components can only be used in the form-block section template! |
To add a new form element, select an already created section of the type form-block and add a new form element to the content area list:
The following gives an overview of the available standard elements and their configuration options and functions.
The content of the form field can be accessed at a later date via the unique identifier or unique group identifier.
For example, if a Mail- / MailUploadLogger is used, this takes place via |
This component provides the user with a form text field.
The component must be assigned a designator which is unique in this form (name
attribute), so that the evaluation of the form and check of its content can work properly.
name
attribute)value
attribute)readonly
attribute)maxlength
attribute)class
attribute)The textarea form component provides a multi-line text input field for the user.
The component must be assigned a designator which is unique in this form (name
attribute), so that the evaluation of the form and check of its content can work properly.
name
attribute)value
attribute)readonly
attribute)class
attribute)This form component can be used to generate HTML radio buttons.
On adding the radio buttons in the Options
area, ensure that a meaningful default is given for each radio button.
The radio buttons are shown with their corresponding designation (labelling), one after the other on the right-hand side of the component.
subcomponent RadioButtons
This component can be added within a form-block section. The values which are the same for all radio buttons are set in this section. The actual RadioButtons are added within a ContentAreaList in this section.
name
attribute)class
attribute)subcomponent RadioButton
This component can only be used within the form RadioButtons component. It is used to add the actual radio buttons within the component named above.
value
attribute)checked
attribute)class
attribute)This form component can be used to generate HTML checkboxes.
When adding the checkboxes in the Options
area it is necessary to ensure that a meaningful value is given for each checkbox.
The checkboxes are shown with their corresponding designation (labelling), one after the other on the right-hand side of the component.
subcomponent Checkboxes
This component can be added within a form-block section. The values which are the same for all checkboxes are set in this section. The actual checkboxes are added within a ContentAreaList in this section.
name
attribute)class
attribute)subcomponent Checkbox
This component can only be used within the form Checkboxes component. It is used to add the actual checkboxes within the component named above.
value
attribute)checked
attribute)class
attribute)This component can be used to provide a password field for the user.
Here too, the editor must assign a unique identifier for the component.
Characters entered are shown in the component as asterisks (*
).
name
attribute)value
attribute)readonly
attribute)maxlength
attribute)class
attribute)This form component can be used to offer the user the convenience of having suggestions for completion of their input provided while they are typing. Here too, the editor must assign a unique identifier for the component.
name
attribute)value
attribute)maxlength
attribute)class
attribute)The form combobox standard component provides the editor with a convenient way of making a selection list available to the form user. The contents of the list and the number and layout are freely formattable. Here the editor must give a unique group designator.
name
attribute)size
attribute)multiple
attribute)class
attribute)The form combobox query component provides the editor with a convenient way of making a selection list available to the form user. The contents of the list and the number and layout are freely formattable. This special SelectBox filters and outputs the selection options from the database via a Query. Here the editor must give a unique group designator.
name
attribute)size
attribute)multiple
attribute)selected
attribute),
).
class
attribute)The form combobox date component provides the editor with a convenient way of making a selection list available to the form user. The contents of the list, the number of entries and layout are freely formattable. Three boxes are automatically generated in this special SelectBox, which can be used to conveniently select a date. Here the editor must give a unique group designator.
To convert into a correct date format within the servlet, a |
name
attribute)size
attribute)class
attribute)This form component enables the user to send files via the form. In addition, it is possible to limit the file formats. Here too, the editor must assign a unique identifier for the component.
name
attribute)valid file type
is activated for the content check.
Several file extensions must be separated from each other by |
.
class
attribute)This form component is used to generate a captcha graphic, a link, which generates a new graphic, and a text field for entering the captcha code, in the form. This component should be used to refuse use of the form by non-human users.
Select the Captcha Validation checkbox in the form-start section so that the input is checked by the servlet. |
maxlength
attribute)class
attribute)Overlapping of the characters is affected by the height, width and number of characters to be rendered (see Chapter Installation and configuration of the web component). Always ensure that the characters are not too easy to read, as otherwise they can be read by spam robots. With the default configuration of 100 x 100 pixels with 6 characters, a captcha can look like this:
Configuration fields for stylesheet classes are provided for virtually every component to enable form components to be quickly and easily adjusted. Each field can therefore be assigned its own individual style by specifying a stylesheet class. An exemplary stylesheet file formedit_css is added to the project when the project component is installed. The class names should be entered accordingly in the configuration fields of the components. We urgently recommend adjusting the stylesheet file to the individual design requirements.
<script type="text/javascript" src="$CMS_REF(media:"formedit_js")$"></script>
In order to be able to use your own stylesheet classes, they must be declared in the HTML header of the (page) templates by means of the <style>
tag, or added to an existing or new stylesheet file in the project.
Javascript functions are used within the templates supplied with the module, e.g. to enable individual form blocks to be shown and hidden. These functions are in the medium formedit_js. The medium must be referenced within the HTML header of all (page) templates in which Javascript functions can be used:
<script type="text/javascript" src="$CMS_REF(media:"formedit_js")$"></script>
This free Javascript framework provides various functions which are used by the templates supplied with the module. In addition, this library is a requirement for use of the form Autocompleter component and form field validation.
The version supplied is compatible with the plug-ins supplied. If an update is necessary, ensure that it is compatible with the plug-ins. |
jQuery can be used in parallel with other frameworks, e.g. MooTools. The framework must be referenced within the HTML header in all templates which use the functions of jQuery or its plug-ins:
<script type="text/javascript" src="$CMS_REF(media:"jquery")$"></script>
Further information and updates: https://www.jquery.com
The jQuery validate plug-in provides a convenient option for checking the form fields used for correct content on entering the data. The form components use the basic functions of this plug-in. This plug-in can also be used to check dependencies between form fields and other limitations and constraints. To use this function in the project, the jquery_validate.js file must be referenced within the HTML header of all (page) templates in which form components can be used:
<script type="text/javascript" src="$CMS_REF(media:"jquery_validate")$"></script>
Alternatively, it is possible to add the function to an existing Javascript file.
This plug-in also supplies the (error) messages in 19 languages, which appear – inline – in the event of missing or incorrect input components. These error messages are deposited in the language-dependent medium jquery_validate_messages and if necessary can be changed and extended. In order for these (error) messages to appear, the medium must be referenced within the HTML header of all (page) templates in which form components can be used:
<script type="text/javascript" src="$CMS_REF(media:"jquery_validate_messages")$"></script>
Further information and updates: https://jqueryvalidation.org/documentation
A jQuery plug-in is also used for the Autocompleter component. However, it only provides the function of setting up a request with the entered characters to another page and displaying the response to the user. The jquery_autocomplete file must be referenced within the HTML header of all (page) templates in which the form Autocompleter component can be used:
<script type="text/javascript" src="$CMS_REF(media:"jquery_autocomplete")$"></script>
Further information and updates: https://github.com/agarzola/jQueryAutocompletePlugin
In real terms, the form Autocompleter component only provides a completely normal text input component. The logic which provides this component with the autocompletion function consists of two parts:
This concept is implemented in the templates supplied with the module on the basis of an example XML file. The logic is implemented on the jsp-side and also requires the Java jdom library.
The Java jdom library is not part of the FirstSpirit™ FormEdit module, but must be separately copied onto the applicationServer or FirstSpirit server or installed as a module.
Further information: |
Example
This example is based on the following XML file (xmlDataBase page template):
<?xml version="1.0" encoding="UTF-8"?> <jobs> <job jobnr="Project Manager (jb-1742-a01)" jobdescription="Project Manager"/> <job jobnr="Apprentice (jb-1743-a02)" jobdescription="Apprentice"/> <job jobnr="Template Developer (jb-1744-a03)" jobdescription="Template Developer"/> <job jobnr="Product Development Manager (jb-1745-a04)" jobdescription="Product Development Manager"/> </jobs>
On using the form Autocompleter field, after entering, e.g. 3 characters, a request is sent to the page referenced in the form component. This page is based on the autocompleterequest page template. Logic is implemented in this page template, which accepts this request and the transferred character chain.
incomingValue = (String) request.getParameter("q");
Within the referenced XML source, the comparator attribute is searched for occurrence of the requested character string.
for (Element child : children) { if (incomingValue == null || child.getAttribute(compareAttr).getValue().toLowerCase().contains(incomingValue.toLowerCase())) { buffer.append(child.getAttribute(resultAttr).getValue() + "\n"); } }
If an applicable entry is found, a response is sent to the form input component:
Project Manager Product Development Manager
The data found is now shown to the form user, e.g. here the value of the jobdescription
attribute (return text).
If the user now selects an option, it is saved as the value of the form field.
This example describes all actions to be performed by the editor, which are necessary to create a form with which a user can register for a competition.
The data entered by the user is to be used on the one hand for a personalised participation confirmation and on the other is to be stored in a database containing all participants.
To carry out this example, the FirstSpirit™ FormEdit module must be installed for a FirstSpirit project, as described in Chapter Installation and Configuration. Furthermore, a database and an available e-mail server are required.
Create a new page in the Page Store and choose the form template. Add the form start, form block_and _form end sections, one after the other in a section area of the page:
Now enter a heading and form name in the form start section.
Choose Post
as the send method and enable client-side content checking.
If you already have a confirmation page and an error page in your structure, you can reference them here.
Now switch to the form block section and create a text field for each of the following: Name, first name, street, house number, post code, town/city and e-mail address.
Use the content check Field filled
on each.
To enable easy filing of the data in the database, it is advisable to choose the column name in the database as the unique identifier.
For this example we use name
, firstname
, street
, housenumber
, zip
, city
and email
as unique identifiers:
All the necessary fields in the form end section are already completed, but you can now adjust them to your wishes.
Create a new page in the Page Store on the basis of the mailtemplate template.
We use the field from the form as the recipient, as the e-mail is to be sent to the form user.
I.e., in this example, %e-mail%
.
You can also define the term yourself, just like the message text and the sender’s address.
You can use %uniqueIdentifier%
in the message text to access all form fields:
Now use Drag&Drop to drag the mail template you have created into the Site Store or reference it via the context menu from the Site Store.
Now switch back to your form start section and add a new data record in the Processing component.
In the following dialog, enter a name for the e-mail processing and choose MailLogger
as the LoggerType.
You can add an optional description.
Now add a new data record to the Logger Parameter component by clicking Add Section
and select the logger-text-value
entry and click .
In the following dialog, enter smtpHost
as the parameter name and the address of your outgoing mail server as the parameter value, e.g. smtp.ANOther.de
.
Repeat this for the encoding
parameter, using the name of the encoding you require (here: UTF-8).
Now create a new section; however, this time using the logger-template-ref template.
Now enter mailTemplatePath
as the parameter name and choose the mail template created by you in the Mailtemplate component.
Further parameters are explained in Chapter Autocomplete request.
Finally, select Activated
status in the component (see Chapter Creating the logger) and click the save symbol in the top left-hand corner.
The logger created by you is now automatically listed in the Processing component, in your form start section.
The second configuration is created in exactly the same way as described in Chapter Creating the logger configuration (e-mail).
However, here you select JdbcLogger
as the logger type and create all parameters on the basis of the logger-text-value template.
Please create the driver
parameter first with the name of your database driver, e.g. com.mysql.jdbc.Driver
for a MySQL database.
Please ensure that the database driver has already been added to the FirstSpirit server. |
Use the url
parameter to pass the address to your database, e.g. jdbc:mysql://muster:3306/formlogger
and the table
parameter to pass the name of your table (here: demo
).
Now create the user
and password
parameters and fill these with the login data for the database, which is usually made available to you by your database administrator.
Further parameters are explained in paragraph Configuring database processing.
Please read Chapter fs-formlogger.ini configuration file.
Then reference all the pages you have created in the structure and, if applicable, release them.
If you or the project administrator have set up the FirstSpirit™ FormEdit module for staging, following generation, your form should be visible in its generated status
(http://www.youreditorialserver.com:8000/fs4staging_<project_id>/…
) and should be able to be used.
The FirstSpirit™ FormEdit module is a product of e-Spirit AG, Dortmund, Germany.
Only a license agreed upon with e-Spirit AG is valid with respect to the user for using the module.
Details regarding any third-party software products in use but not created by e-Spirit AG, as well as the third-party licenses and, if applicable, update information can be found in the file THIRD-PARTY.txt
included with the module.
This document is provided for information purposes only. e-Spirit may change the contents hereof without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. e-Spirit specifically disclaims any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. The technologies, functionality, services, and processes described herein are subject to change without notice.