TODOS
-----
- Test path generation for PageLocalization
- Plan out implementation of Content classes — how they register with the page
  class, how can they be stubbed out when a template changes
- Update page delete notice to warn about removing sub-children
- Have locales destroy page localizations
 
NOTES
-----
- Templating
  - Create a TemplateSection model
  - A TemplateSection instance specifies the Content class it wants
  - It can also specify certain constraints. For example it might specify
    a range of content instances. Say 1..8 images.
- Auto-generating records
  - Since there are many intermediate models and localized versions, there 
    needs to be plenty of automatic generation of models
    - Add a page, have the content models and localizations stubbed out
  - This is further complicated by the need to update records when the 
    template changes
    - You may need to add more records
    - You may need to assign them to different sections in the template
    - Where the system gets that wrong, the user needs to be able to easily
      correct it
    - Any records that don't fit into a new template need to be marked as
      orphaned. The user then needs to have the option of deleting, swapping
      or merging with another content block.
  - Events
    - Adding new page
    - Changing page template
    - Adding Locale
      - Generate new localizations and articles for localization
    - Removing Locale
      - Destroy page localizations and content localizations
- Path Caching
  - For quick queries, we will cache the full path to a page in the DB
  - The path itself will also be localized. Any changes to the parent slug
    will affect the child pages.
  - Localizing slugs for localized pages is optional. If they're not defined,
    they fall back onto the slug defined in the page.
  - This means a path stored in a localized page may have been calculated from
    localized and default slugs.
- Error handling
  - Template errors; When a template is missing or broken, raise a custom 
    error and try to give the users some guidance on correcting it.
  - Custom errors for missing locales/dialects, which the exceptions 
    controller can then catch and display a nice message.
- Localization
  - There needs to be some way to set defaults — to handle fall backs — and 
    turn off the localization and internationalization.
  - With locales/dialects turned off, all the auto-generation code needs to 
    account for it and generate using a default. 
  - The interface may also need to change slightly to mask the existence of 
    localizations. Since this is a common case, it's worth thinking carefully 
    about.
  - The localization/internationalization split is mutually-exclusive, so we
    need to have a simple option which let's us check in the back-end — then
    we can display the correct controls on a form, the models could even
    guard against at dodgy stuff.
  - Choosing locale/dialect
    - Use the URL first, then the Accept-Language header, final fall back is
      the default — in the future this might even be set using GeoIP
    - Encoding the locale/dialect into the URL need to be configurable. For
      example, we may wish to use a subdomain for a locale and an entry in
      the URL to indicate a dialect.
- Settings
  - Need to be modifiable at runtime
  - Localization/Internationalization
    - Path/URL formatting
- Authentication
  - We need to have authentication for both the administration and for the 
    public side.
  - The public authentication will be arbitrary — it will change on an install
    by install basis. 
  - Investigate using merb-auth-core. Use it for authenticating the backend, 
    but also expose it so that it can be used in code in the front-end
- Content
  - These belong_to the Page model and are registered as special content 
    classes.
  - May or may not be localized and can have their own strategies for 
    fallbacks if a locale is missing.
  - For editing, these classes can have a custom partial, which will then be 
    put inline when editing the page.
  - Example classes
    - RichTextContent
    - PlainTextContent
    - ImageContent; may specify things like image size, caption etc
- Asset Manager
  - Assets consist of an Asset model which has n AssetLocalizations. The
    localization models contain a localized description of the asset and
    point to the localized version of the file — say a splash image which has
    translated text for each locale.
  - Uploaded assets can be browsed by date, type (PDF, Video, Image) or 
    collection.
  - A collection is way of organising assets. They don't behave like folders.
    The assets sit in a flat namespace. Collections are just a way of grouping
    related assets. An asset may belong to multiple collections.
  - Searching; obviously users will want to be able to search. It should look
    in the asset name, description and perhaps for text-documents, the actual
    content — this could be done by parsing the content on upload and stashing 
    it in an indexed_content field or similar.
  - Browsing
    - When selecting an asset to attach to a page, we need a dialog which
      allows the user to browse and search for an existing asset. They also
      need to have the option of uploading a new asset from the same dialog.
      When the user has completed using this dialog, it returns a asset id.
    - Processing; when attaching an asset, it may need to be 
  - Uploading
    - Extract meta-data from files where possible — exif in images etc.
    - Store file sizes
    - Generate previews
    - Store on disk, organised by locale/dialect