Index & Hierarchy API: browsable data display based on (virtual) hierarchy.

Official proposal at GSoC.

Introduction

Vocabulary Index is an increasingly popular module that allows people to browse taxonomy in a variety of ways. The key element of this module is its simplicity: administrators can set it up and configure it with no more than a few clicks. After the introduction of version 2, I got numerous requests for integration with other modules, like Views and Transliteration, and other data sources than Taxonomy, like CCK.

Proposal

I want to create two new modules. The first is Hierarchy API. This will become a standard API for creating and manipulating hierarchies. Other contribs like Hierarchical Select are likely to make use of this. The second new module will be Index, which will succeed Vocabulary Index. Index will allow site administrators to create pages or blocks where visitors can browse hierarchical content (Taxonomy, Books) or content that has been put in a virtual hierarchy (Users > Nodes or Terms > Nodes, for instance). To do this, Index will depend on Hierarchy API.

1. Hierarchy API
   1. Create hierarchies based on Drupal data
      Hierarchy API will convert Drupal data to hierarchies in a standard format, usable by Hierarchy API itself or other modules.
   2. Manipulate and traverse hierarchies.
      API functions will allow modules to access, manipulate and traverse the entire hierarchy or single layers or items separately.
   3. API
      Through hooks modules can define which data types they can convert to the standard format used for hierarchy items. Hierarchy API will support basic data types as found in core and CCK, but through the API any kind of data can be inserted into hierarchies.
2. Index
   1. Virtual hierarchies
      Every index page or block can display a virtual hierarchy. A lot of data is related to eachother, but not necessarily hierarchical by default. Using relationships between data types (Users and nodes are related through the uid field, for instance) virtual hierarchies can be generated and displayed to users.
   2. Views integration
      If Views has been enabled, a Create as view checkbox will be available when creating a new index. When checked, Index will automatically create a view that acts as the index' data source. Using Views UI, people can customise the data result set into detail.
   3. Transliteration integration
      Transliteration is now being done like in Pathauto 1 with a custom transliteration file. In the future we will use Transliteration.module, as it is more flexible than the current custom approach.
   4. Better template support
      Currently, all lists have the same markup. They only differ in that they can have different CSS being applied to them. For more custom theming, we need theme callbacks with wildcards, like Views does.
   5. Theming
      The display modes are different on a technical basis. However, administrators may want to display like like Taxonomy List does, using term images. I want to add extra template files and CSS so administrators can easily theme indexes by copying and pasting those files.
   6. Independence
      Index will be fully functional on its own. However, the presence of modules like Views, CCK and Transliteration will enable extra features. This way, Index' development will not be hindered by other modules, but it will still integrate with them. Example: we don't have to wait for Views for Drupal 7 to create a D7 port of Index.
   7. Interface
      The interface is one of the most important parts of Vocabulary Index. Its simplicity is greatly appreciated and therefore it needs to be maintained, despite a lot of new features being added. I want to add live previews and use AJAX to handle form submission, so creating new indexes will go more fluently.
   8. API
      Hooks will be added to define display modes (browsable, threaded, alphabetical, etc.)
   9. Documentation
      Documentation will be written in the form of Doxygen comment blocks, help and handbook pages. Also, API docs will be made available at api.nederdev.com.

Road map

1. May 23
   Get familiar with the Views and CCK APIs and discuss what people want exactly. Write down a plan based on the possibilities and people's wishes. Also define the standard format for Hierarchy API's hierarchies.
2. June 20
   Finish Hierarchy API. Test performance. Write documentation.
3. July 31
   Finish basic version of Index. Index pages and blocks can be made. Basically everything without Views integration.
4. August 10
   Views integration.
5. August 17
   Adding AJAX and bug hunting. Dot the i's regarding the interface. Write documentation. Make it ready for a release.

Communication

I want people to be involved, because this project is something to be used by those people. Everything I do will be posted at g.d.o and my blog at nederdev.com so people can track my progress and comment.

Profit for Drupal

• Maintainers will have access to a general API for creating and manipulating hierarchies. Modules like Hierarchical Select may profit from this very much.
• Views will be more powerful with new ways to display data.
• Drupal will have an easy-to-use system to browse any kind of data. Both for administrators and end users it will be extremely easy to set up and use Index.

Difficulty

Medium/hard.
Hierarchy API needs very good performance. I expect Views integration will be relatively hard.

Mentor

• bangpound

  At DrupalCon DC I have done the Taxonomy Revisited talk with him, Benjamin Melançon and catch.

About me

I am Bart Feenstra, known to some as Xano, to others as Kaaskop, although I recently changed that IRC nickname to Xano_ to match my (groups.)drupal.org username. I am a twenty-year-old student at the University of Twente (The Netherlands), where I am a first-year bachelor student in Communication Studies.
Regarding Drupal I am mostly active in the Dutch community, helping people out on the forums and IRC and organising events (DrupalJam, the bi-annual Dutch DrupalCon; Kroegmeet, intended for socialising and expanding your network). Next to that I maintain several modules (Vocabulary Index, External links filter, External Search) and write patches for Drupal 7. I have an excellent understandig of HTML, JS and CSS. My PHP skills are good as is my knowledge of Drupal and the API.