Skip to content

Core API

czheng edited this page Jun 3, 2011 · 4 revisions

Background

Symphony 2's internal classes were inconsistent and often difficult to use. Symphony 3 should implement a consistent core API across all classes that is easy to use.

The following was proposed during Symphony working group meetings on 19 April and 10 May 2011 (transcript). Draft 2 prepared by Craig Zheng on 3 June 2011

Proposal

Implement a thorough and consistent API model that can be used throughout the core. Should be accessible via REST.

Scope

The Core API technically is comprised of all the public methods and properties of all the classes in the core.

In Symphony 3 this will be a bit more broad, in part because S3 will take steps in the direction of a proper framework.

Goals

The goals of the API are simple, and are inspired by Trolltech's The Little Manual of API Design.

Symphony 3's API should be:

  • Consistent
  • Easy to use
  • Easy to learn
  • Hard to misuse
  • Produce readable code
  • Extensible

Approach

Rowan's been good enough to begin compiling examples. See example 1 and example 2 on pastie (those may not be up to date), and his development repo (more recent).

Next Steps

  1. Use Cases

    Compile lists of API use cases so that proposals can be tested against each.

    → see API Use Cases

  2. Diagram

    Start by producing a UML version of the API before coding anything. UML to proceed in stages, beginning with Sections/Entries/Fields.

Clone this wiki locally