API Standards for MDPro 1.1 and Beyond

Basic folder structure for MD 1.1

cache
config
docs
images
includes
install
javascript
language
libs

adodb
cache
config
log
pear
phpmailer
phpsniff

logs
modules

AddStor
Admin
Blocks
Credits
Errore
Home
Login
MDMenus
MDUser
Modules
News
Permissions
Search
Settings
Stats
Tinymax
Topics
NewModule

Blocks
doc
images
lang
templates

overrideSiteURL

themes

aTheme

images
lang
style
templates

overrideModule

overrideSiteURL

upload
core module

Core feature

Just to remember the features that we MUST offer to a customer or that a product like MD must have to best others:

1. Management of user, groups and assigning policy (ACL) for each component or functionality of the product
2. Offering the chance to authenticate towards different repository (LDAP, DB other)
3. Producing XHTML output and managing layout with CSS2
4. Generating output from HTML templates and not having HTML mixed into php code.
5. Having good performance (goal is to reduce memory usage and reducing time to serve a page)
6. Working with possibly more than 1 DB (mySQL as default but Oracle as second)
7. Security: a lot of things … being not vulnerable (using external libs help also this since there should be less risk of something affecting us first); managing users correctly with passwords (both registration, password complexity, expiration), inactive user monitoring, etc.)
8. Being configurable: all the stuff must be configurable by the administrator.
9. Managing resources in a centralized way (images uploaded can be used by any modules and managed in the same way)
10. Giving access statistics for the site even if basic data, but we have all the relevant data in the DB.
11. Having a search engine across the site
12. Managing errors and displaying them nicely
13. Managing menu, breadcrumbs and title so that people don’t have to develop it anew
14. Having topics centralized across the site so that no longer does each module create its own data and having ACL on topics helps giving access to the correct data.
15. Allowing editors to insert content easily without having to know HTML.

Rules for development

All libs must find a place in the lib folder

Reason: libs must should be used by more than a module and in this way we can converge towards a single piece of code for resolving a particular need.

All javascript must find a place in the javascript folder

Reason: the path is known and usable throughout all the site. Also, we need to converge towards just a single piece of code for a specific function. This way if we have a bug we fix it for all the code using it. We also give users a coherent behavior and not use one thing in one module and something a little different in another. We must remenber that customers do not understand nor are interested in modular design or freedom of choice of single developers and we want to manage to do better business.

All the stuff tied to a theme MUST be placed in the theme folder

Error page or things like this have to migrate from users module or render module; we all want our site to be coherent to itself. Login stuff will be placed into the login module templates

Catalog

Javascript

Component	Need	Tool
Client data validation	Validate input fields before sending to server	Validation - http://groups.yahoo.com/group/validation
HTML editor	Edit text in a rich text editor	Tiny_mce
Dynamic menu tree	Display a dynamic menu in browser	PHP Layers Menu - http://phplayersmenu.sourceforge.net/
Tab folder	Display tab folders in browser	Tab Pane - http://webfx.eae.net/

PHP libs

Template engineLogCacheConfigurationCAPTCHAMail protocolBrowser data identificationPDF

Component	Need	Tool
DB access	Accessing DB	Adodb – adodb.sf.net
Managing templates for HTML output
Logging data	Log – pear.php.net
Caching data	Cache_lite – pear.php.net
Managing configuration file	Config – pear.php.net
Generating an image for security
Sending e-mail and also accessing it	Phpmailer – phpmailer.sf.net
Getting information about client agent	Phpsniff – phpsniff.sf.net
Converting data to PDF

Open points

We have a lot of folders with similar meaning and stuff that lies there from the beginning of time: one example is images folder and all the images into theme, and modules. Should we set some rules of what goes into each folder?

New 1.1 modules

Login

This module allows for different login policies for the site.
Each policy or LoginService is loaded as a plugin for the system.
The folder organization is the following:

Login
blocks
doc
images
lang
loginServices

and has a plugin for the new Settings module that must be placed into the Template folder of the Settings module:
To create a new LoginService all is required is to create a new class named myLoginServiceName.class.php and place it into the loginServices folder. The class must extend baseLogin.class.php There are the following methods to implement: getCredentials

Usually login just requires user and password. This method can check additional data. Since data for each login service is unknown, this is the place where the check logic for additional data can be implemented as in the case of the CAPTCHA form. Here we’ll check the graphic string.
If this method returns true the engine goes on checking user and password.
This method returns true by default.

forceOverrideAuth
getSearchField
getPassword
getSearchFieldData
createLoginArea
createLogoutArea
getLoginData

Some login forms might need to generate something like a CAPTCHA image or other things. This is a method that can be used for this goal.