Public Interest Tailor Module Stakeholder Requests: Version

You might also like

Download as doc, pdf, or txt
Download as doc, pdf, or txt
You are on page 1of 6

Public Interest

Tailor module
Stakeholder Requests

Version <1.0>
Tailor module Version: <1.0>
Stakeholder Requests Date: <dd/mmm/yy>
<document identifier>

Revision History
Date Version Description Author
<15/NOV/2006> <1.0> Initial revision Brandon
<16/NOV/2006> <1.0> Revision Hamad nazir

Confidential ÓPublic Interest, 2000 ii


Tailor module Version: <1.0>
Stakeholder Requests Date: <dd/mmm/yy>
<document identifier>

Table of Contents
1. Introduction 1
1.1 Scope 1
1.2 Definitions, Acronyms and Abbreviations 1
1.3 Overview 1

2. Assessment of the Problem 1

3. Recap for Understanding 2

4. Feature list and importance 2

5. Analysis of individual features 2


5.1 Ability to alter forms without writing a custom module 2
5.2 Ability to create and delete alterations through the Drupal administration interface 2
5.3 Ability to control the module via the database 2
5.4 Speed 2
5.5 Ability to use “PHP mode” to define the behavior 2
5.6 Disable/enable module without side effects 3
5.7 Scalability 3
5.8 Security 3
5.9 Conditional execution of alteration rules 3

Confidential ÓPublic Interest, 2000 iii


Tailor module Version: <1.0>
Stakeholder Requests Date: <dd/mmm/yy>
<document identifier>

Stakeholder Requests
1. Introduction
1.1 Scope
This document covers the design of a Drupal module that can be programmed to alter arbitrary Drupal forms in
arbitrary ways, without the need for the site developer to create a custom module.

This project is being done using the infrastructure provided by the Drupal project for use by independent
contributors.

The module itself will be available for use by all users of Drupal.

1.2 Definitions, Acronyms and Abbreviations


Drupal – A content management system (CMS) designed to be completely flexible.
Block – A Drupal sidebar that can be placed into any region of a site’s theme.
Module – A unit of functionality in Drupal. Modules implement the behavior of a Drupal installation.
Form – Web forms in Drupal are proper objects that can be passed around.
FAPI – The Drupal Forms API allows for completely flexible web forms that may be extended by modules.
Node – A unit of content in Drupal. A node is all the data that interested modules associate with a specific node id.
Node id – An integer used to reference a Node.
Hook – Drupal uses a callback mechanism. At certain points during page execution, Drupal calls hooks to allow
modules to modify and add behavior.
PHP mode – Some modules allow developers to specify behavior by writing raw PHP code. A notable example is
the Blocks module, which allows using arbitrary PHP code to determine whether a block is visible or not. Access to
PHP mode is strictly controlled by ACLs.
Theme Regions – Placeholders in a Drupal theme that blocks may be rendered into. Common regions are “left side,”
“right side,” “header,” “footer,” and “content.”

1.3 Overview
This document is organized into an introduction, an assessment, and a list and analysis of features.

2. Assessment of the Problem


Drupal has the ability to alter any of its forms prior to display. This is accomplished using a hook named
hook_form_alter. This hook is available for use by modules. The learning curve for performing this action is steep,
however, as the site developer needs to know how to write modules. The ability to alter forms through an easy to
use interface would make it easier for inexperienced site developers to alter forms.

The problem of Altering Drupal forms


Affects Site developers without experience with module
development
The impact of which is Ugly workarounds and theme hacks
A successful solution would Be easy to use and effective at the stated task of altering
forms

This module will be designed with ease-of-use in mind. There are many modules that alter forms, but there are no
modules currently available that will allow the site developer to create alterations through the web. This module will
reduce the dependency on one-off “site customization” modules that implement the desired alterations to a site’s
forms and allow for easier customization by the end user, as well as additional flexibility.

Confidential ÓPublic Interest, 2000 1


Tailor module Version: <1.0>
Stakeholder Requests Date: <dd/mmm/yy>
<document identifier>

3. Recap for Understanding


Drupal has the ability to alter forms, but no way to access this functionality directly. Developers must create a
module to hold the form altering logic. This problem can be solved by creating a module that can be programmed
through the web to perform these form altering tasks.

4. Feature list and importance

Ability to alter forms without writing a custom module High (Purpose of the module)
Ability to create and delete alterations through the High
Drupal administration interface
Ability to control the module via the database Low
Speed High (Hooks are like interrupts, they need to be fast)
Ability to use “PHP mode” to define the behavior Medium
Disable/enable module without side effects High (Drupal modules are expected to be well-behaved)
Scalability Medium (Even the largest sites have no more than a few
dozen custom alterations.)
Security High (Unauthorized access to the facilities provided by
this module could be used to compromise the entire site)
Conditional execution of alteration rules Medium

5. Analysis of individual features


5.1 Ability to alter forms without writing a custom module
The goal of this module is to allow users to alter forms without creating single-use modules to perform this task.

5.2 Ability to create and delete alterations through the Drupal administration interface
The ability to use the normal interface means a lower learning curve. Users are uncomfortable using modules that
require configuration that can not be performed via the administration interface.

5.3 Ability to control the module via the database


Power users and site integrators may want the ability to manually insert, modify, and remove alterations using an
SQL client rather than the administration interface. Having a simple and well planned schema will allow this.

5.4 Speed
This module will be consulted every time a form will be rendered. This may happen several times on a single page
view. It is essential to maintain a good speed, and not adversely affect the speed of forms that have not been altered
via this module.

5.5 Ability to use “PHP mode” to define the behavior


Sometimes, complex behavior is needed that cannot be described through a point-and-click interface. Having the
ability to use arbitrary PHP code is needed for those cases.

Confidential ÓPublic Interest, 2000 2


Tailor module Version: <1.0>
Stakeholder Requests Date: <dd/mmm/yy>
<document identifier>

5.6 Disable/enable module without side effects


A module may be unloaded at any time. Any changes made to the database must not affect the normal operation of
other modules.

5.7 Scalability
Drupal sites come in all sizes. A site with many customizations and many users must maintain a reasonable response
time. Care must be made not to introduce bottlenecks.

5.8 Security
The ability to alter forms is a powerful tool that may be used to break security if it is accessible by people with
malicious intent. Proper access checks must be made at all times to prevent the module from introducing security
holes.

5.9 Conditional execution of alteration rules


The ability to define conditions under which alteration is performed would be useful, and add additional power.
Implementation of this is not a necessity, though. People who need this level of control may want to use a custom
module instead.

Confidential ÓPublic Interest, 2000 3

You might also like