Technical requirements

(Derived from http://confluence.sakaiproject.org/confluence/display/SCP/Criteria+for+Provisional+Status)

Source

The tool must be written in Java to compile with Java SE 1.5, to run in the Tomcat container.

Source code management

  • Source must be managed in Sakai's contrib svn area.
  • Issues (bugs, tasks, feature requests) must be managed through Sakai's JIRA issue tracking system
  • All checkins to svn should have associated JIRA issue numbers.

Licensing

Source must be licensed under the ECL 2.0 open source license. All committers must sign a individual CLA license agreement, and their employers a CCLA agreement. The tool cannot require other applications or jar with a proprietary or ECL-incompatible license.

Presentation technology

  • The tool must use RSF
  • HTML templates should validate.

Database / ORM

The tool must use Hibernate, and work successfully with Sakai using HSQL (in-memory), mysql and Oracle.

The tool must work properly with the Sakai AutoDDL approach. The application must properly create tables and indexes when tables do not exist and the tables must be named so as not to conflict with other Sakai tables.

All database access to tables that the tool does not own must take place via published Sakai APIs provided by the application that manages those tables. The tool should use APIs for access to its own data, but it must use APIs for access to data from others.

The tool must use the system-wide configuration (sakai.properties, ServerConfigurationService) and not require any local configuration to be hand-edited.

The tool must properly operate in the Sakai Authorization and tool placement structure, and must use existing appropriate security functions (site.upd for Permissions and Options) and introduce new security functions for the application.

The tool must fully work in a clustered Sakai application server environment.

There are a number of system-wide elements in Sakai including Spring, Hibernate, and others--the application must work with the versions of these elements that are part of the Sakai release.

Interaction and Visual Design

The tool must properly inherit skins and layout styles from Sakai (i.e. when the sites color changes the tool colors change as well). The tool should not look "out of place" amongst other Sakai tools. Tool-specific styles should be in its own CSS file and kept to a minimum.

UI components available in the Sakai library should be used where possible (e.g. wysiwyg editor, calendar, paging widget).

The application must support all of the browsers currently supported by Sakai including FireFox/Mozilla and Internet Explorer.

The tool should provide basic help which integrates seamlessly with the Sakai Help system. The help should have a look and feel and writing style similar to the other elements of help.

Code structure

  • Persistence or business rule code should be factored into a Sakai Component with a published API which has complete javaDoc. This component should be designed so as to allow other applications and/or system processes to be able to work with the business objects handled by the application.

Localization

  • The tool must be properly internationalized with all of its user-displayed strings derived from properties files.

Use of entities

  • The tool must support entities, and implement entitycontentproducer so that artefacts (questions and answeres) are indexed and searchable by the search service. Entity support should be implemented using the "entitybroker" code currently in contrib (https://source.sakaiproject.org/contrib/caret/entitybroker/)

Import/Export

  • The tool should participate in the Sakai cross-site import and export services.

Events

  • The tool should generate event codes that are triggered minimally on new, revise, and delete actions on the basic objects created by the tool.

Accessibility

  • Markup and UI components should be accessible, i.e. usable with screenreaders and other assistive technology.