Contact form

The contact form described within this chapter includes securing recipient addresses from grabbers and bots that gather
e-mail addresses from web pages. The list of recipients can be configured and extended as needed. The module can be
included in any application via the <core:importdesign /> tags at any position.

Formatting of the module's output is done by an appropriate CSS file. As a template you may want to use
shipped CSS file /modules/contact/pres/css/contact.css from the release package. It must be added to
the head of the corresponding page. This file contains a basic set of formatting for the module,
that must be adapted as desired. A detailed description of the generated HTML code can be taken
from the wiki chapter
Kontakt-Formular-Modul
(German).

The subsequent sections describe the configuration of the module to prepare it for usage within different applications
and with labels in different languages. Further, the structure and the construction of the software is discussed.

To be able to integrate the contact form module in various projects the project specific parts must
be outsourced to application configuration files. Configuration is necessary in two flavours: first
of all the recipients must be configured, second the texts of the form tag libs (validators) must
be defined per project.

The Adventure PHP Framework features several options to create multi-language applications or modules. Basically,
the language is held within every single DOM node or service layer. This property can be used to display language
dependent texts using a document controller or XML tags like

<html:getstring />

<template:getstring />

<form:getstring />

For details, please see Standard taglibs. The contact form uses XML tags
within different areas. The content is based within a common translation file:

To structure the software folders data, biz, and pres have been created. Within
pres one folder for both controllers (controller) and view components (templates) are
contained. Further, folder css contains a sample stylesheet.

Implementing custom modules it is not recommended to store them within the modules folder since this might
break the update path. Since the contact module is part of the APF this is appropriate here.

Template file contact.html defines the skeleton of the module. It contains the headline displayed by a
<html:getstring /> tag from the translation file and a <core:importdesign /> tag that
displays the dynamic area: either the form (default) of the thanks page.

Within the above template file the <core:importdesign /> tag is used with the pagepart
option in effect. this means that depending on the URL parameter contactview a corresponding template from
the given namespace is included. In case no URL parameter is given, the default template specified along with the
template attribute is displayed - the form.

Within file thanks.html the thanks message is defined, that is displayed on
submission of the form. Also in this case the message is taken from the translation file. This means, that no
document controller is required:

As mentioned in chapter 3.2 a document controller is required to manage the user input.
Thus, the ContactFormController takes responsibility for filling the recipient list as well as handling an
incoming contact request.

Chapter (Document-)Controller describes the implementation of document controllers. In general, a custom controller
implements the DocumentController interface or derives from BaseDocumentController respectively. In
this case the controller used the second option which is recommended anyway - ContactFormController inherits
from BaseDocumentController.

Managing the use cases described above method transformContent() is implemented. It shows the form as long as
the user input is valid. If true, it and picks up the form values and sends the form using the business component
ContactManager:

Creation of the business component is done by the ServiceManager.
This framework component is able to create objects and initializes them for usage within the APF context. Details
can be taken from section Services.

ContactManager::sendContactForm() takes an instance of ContactFormData as an argument to send the
form and display the thanks page.

Class ContactManager is the business component of the module. It encapsulates the business logic and talks to
further interfaces or application layers (e.g. data layer, e-mail sending engine).

Essentially, the ContactManager offers two services: loadRecipients() to retrieve the list of
recipients and sendContactForm() to send the contact form. ContactFormData and
ContactFormRecipient have been introduced to abstract and encapsulate the form data as well as the recipient
list.

Reading the recipient list has been encapsulated into a separate component within the contact module - the
ContactMapper. It implements a data mapper that returns either a list of recipients or a single one via
ContactFormRecipient.

Recipients are defined within configuration file

Code

/APF/config/modules/contact/{CONTEXT}/{ENVIRONMENT}_recipients.ini

The file contains one section per recipient. The schema of one section is as follows:

APF configuration

[Contact ([0-9]+)]
recipient-name = "(.*)"
recipient-address = "(.*)"

The ContactMapper exposes two methods: loadRecipients() returns a list of all recipients and
loadRecipientById() returns exactly one specific:

In order to provide a state-of-the-art web experience and to continuously improve our services we are using
cookies. By using this web page you agree to the use of cookies. For more information, please refer to
our Privacy policy.