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

• islandora/collection

• islandora/mnpl_advanced_search

• islandora/ingestObject

• islandora/list_terms

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

• fedora/tagging/add_tag/js

• fedora/basket

• fedora/repository/addToBasket

• fedora/repository/removeFromBasket

• fedora/repository/add_search_results_to_basket

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)

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