Drupal 7 Design Document

Drupal 7 Design Document

Overview and General Architecture/Philosophy

Islandora 7 Core

Menu System

Islandora 7 Menu Paths
I think that we should replace fedora_repository with islandora in islandora 7. It does pose a migration issue however. The question is do we register both menu paths or do we make a clean break?

We should decide on a convention, either:
islandora/{pid}/{dsid}/{function}
islandora/{function}/{pid}/{dsid}
So we are consistent throughout the path API. We also need to decide on a naming convention for the paths camelCase or with_underscores. We should also decide on camelCase or CamelCase. This is also true in our code, but our external paths especially.

• admin/settings/islandora
  The main islandora admin page. Has all the options for core islandora. We could continue using the tabbed interface and allow other islandora modules to expand this page by adding their own menu paths and display them in tabs. I think this is a reasonable way to handle solution packs. We will have a solution pack module that adds to this path, like admin/settings/fedora_repository/demoobjects in islandora 6. Should the solution pack module stay part of core so that the inital demo objects can be installed?
• admin/settings/demoobjects
  See the question above.
• islandora
  • /
    This brings up the collection view of the top level collection that is specified in the admin page. The display collection hook will be called with the argument of the top level collection.
  • /{pid}
    Brings up the {pid} in question. It will call the view object ( and view collection ) hooks.
• islandora/service/{pid}/{service_pid}/{service_method}
  This is a way to get the dissemination of {pid} using the {service_method} of {service_pid}. Not sure if we should keep this one. I don't see anyone using it currently. This could potentially go into the restful path module that Nigel would like to create. Would this invoke a hook for dissemination? I'm not sure I see a use case for that hook.
• islandora/object_download/{pid}/{dsid}
  This will prompt to download {dsid} of object {pid}. Very similar to islandora/{pid}/{dsid} except that this prompts to download. I wonder if we should put all the functions to deal with datastreams under a path of: islandora/{pid}/{dsid}/{function} so this would become something like islandora/{pid}/{dsid}/download.
• islandora/editmetadata/{pid}/{dsid}
  Edit the metadata of {pid}/{dsid}. Should we specify the DSID here? This will call a hook so we can have different form builders.
• islandora/purgeStream/{pid}/{dsid}
  This would call the purge datastream hook. Things like this seem to be replicated in that this path exists, but there is also a form that does the same thing in core. Is that okay? Does this belong to a restful path API instead of here?
• islandora/replaceStream/{pid}/{dsid}/{label}/{collection} This would call a hook as well. Do we need this? Do we replace streams that often. Seems like a strange path to me.
• islandora/purgeObject/{pid}/{name} Allows to purge an object.
• islandora/addStream/{collection_pid}/{collection_name}
  Does this add an object to a collection or add a stream to an object. It seems to do the latter, but it is named like it would do the former. We should potentially clean this up. This can't be used very often because it is broken in the current code. It references a undefined variable that is indeed undefined.
• islandora/collection/{pid} This page presents a collection view. I don't think this is necessary. We should probably not distinguish between an object and a collection that deeply.
• 'islandora/ingestObject/{collection_pid}/{collection_label}/{content_model}' Ingest a new object. Hooks around this. Only way to access this?

Menu paths removed

• admin/settings/islandora/collection
  This menu path seems superfluous. It displays the same settings as admin/settings/islandora. If needed it can be kept.
• islandoracm.xsd
  Because we are separating out the visual aspect, this should be removed from core.
• collection_policy.xsd
  See above
• islandora/mnpl_advanced_search
• fedora/tagging/add_tag/js
• fedora/basket
• fedora/repository/addToBasket
• fedora/repository/removeFromBasket
• fedora/repository/add_search_results_to_basket
• islandora/list_terms
  this can go into the solr module, not here

Hooks

• Ingest
• hook_islandora_pre_ingest
• hook_islandora_post_ingest
• Datastreams
• hook_islandora_pre_add_datastream
• hook_islandora_post_add_datastream
• Purge
• hook_islandora_pre_purge
• hook_islandora_post_purge
• Edit Metadata
• View Object
• View Collection

Permissions

• Existing Permissions
• add fedora datastreams
• edit fedora meta data
• ingest new fedora objects
• purge objects and datastreams
• view detailed list of content
• view fedora collection
• New Permissions
• Add datastreams
• edit metadata
• ingest
• purge
• view collection
• view object

Coding Best Practices (global conventions)

Adding a settings page to your module:
The Islandora 7 Core module sets up a Islandora settings page. This page is a form that has a vertical tabset where every module that plugs into islandora will put its settings.

Here is the general form for doing this:

<?php
/**
 * Function documentation header that we all should be using.
 */
function [module_name]_form_islandora_admin_settings_alter(&$form, &$form_state, $form_id) {
  // Add yourself a new fieldset which will be rendered as a tab on the islandora settings page
  $form['module_name'] = array(
    '#type' => 'fieldset',
    '#title' => t('Jonathans Amazing Settings'), // The name of your settings page
    '#weight' => -8,
    '#group' => 'settings',
  );

  $form['module_name']['setting_name'] = array(
    '#type' => 'textfield',
    '#title' => t('Amazingness Factor'),
    // the setting is saved as the name of the field
    // as with everything in drupal this should be prefixed with the module name 
    // to avoid collisions
    '#default_value' => variable_get('setting_name', '52'),
    '#description' => t('On a scale of 1 - Amazing, how amazing is it?'),
    '#required' => TRUE,
  );

  $form['module_name']['other_setting_name'] = array(
    '#type' => 'checkbox',
    '#title' => t('Another Setting!'),
    '#default_value' => variable_get('other_setting_name', '1'),
  );
}

This is all passed into system_settings_form.

Every module must have a read-me

If it installs something, it must have an install file

Tests

Documentation

Drupal 6 UML Document

Drupal 7 UML Document

Modules

What is a Module?

What is a Content Module?

What is a Solution Pack?

Islandora-specific datastreams

Collection Policies

Ingesting (omn0mnOM)

Use Cases

Security