Audean Wiki

User Tools

Site Tools

You are here: Audean Wiki for Mediacore services » G2 Glossary (G2) module for Drupal » Warning
Trace: • Warning
g2:choosing_next

Table of Contents

Warning

This is a 2008 work-in-progress page for NancyDru, fgm and eafarris, to update http://drupal.org/node/266511 but never completed at the time. In 2011, update Choosing a glossary module instead.

Features checklist

Features checklist

Glossary and G2 Glossary are both targeted to sites needing a glossary section. However, the modules are quite different, targeted to different types of glossary needs, and once you choose one, it will take a significant amount of work to switch to the other one after the fact, so the current maintainers of the two modules have set up this page to help you choose which module you should probably be using, or if you should really write your own.

Feature Glossary G2 Glossify

Drupal-related
Entries implementation Storage Terms Nodes Nodes
Revision support No   Yes Drupal core Yes Drupal core
Drupal 7.x Dev branch No   No port announced No  
Drupal 6.x Yes Release Yes Dev Yes Release
Drupal 5.x Yes Release Yes Dev No  
Drupal 4.7.x Yes Dev Yes Release No  
Drupal 4.6.x Yes Dev No   No  
Earlier versions Yes CVS No   No  
Documentation README.txt README.txt README.TXT
Handbook Wiki
 
AJAX UI No   Yes Entry selectors No

Services provided
Glossaries per site Multiple Single Single
RSS feeds On entries Yes Drupal core No   Yes Drupal core
On content tags No   Yes Drupal core Yes Drupal core
Classify entries using taxonomy No Entries are terms already Yes Drupal core Yes Drupal core
Commenting on entries No   Yes Drupal core Yes Drupal core
Editor-only information No   Yes   No CCK
Feature blocks Alphabar No   Yes   No Views
Daily Yes   Yes   No Views
Latest No   Yes   No Views
Random Yes   Yes   No Views
Search glossary Yes   No   No  
Top No   Yes   No Views
XML-RPC services provided Alphabar No   Yes   No  
Daily No   Yes   No  
Latest No   Yes   No  
Random No   Yes   No  
Top No   Yes   No  

Security
Drupal core Yes   Yes   Yes  
XML-RPC IP-based access control No   Yes   No  
Throttling No   Yes   No  
Alphabar maintenance Automatic Manual No  
Input filtering Automatic <dfn> elements No  

Performance
Memory needs vs number of entries O(n) O(1) O(n)
Speed on small glossaries Faster Slower Slower
Speed on larger glossaries Slower with size Remains constant Slower with size
Themeability Search form
Yes   No Drupal core No Drupal core
Node overview Yes   No   No  
Individual entries No   Yes   No Drupal core
Each feature block No   Yes   No  
Each part of an entry No   Yes   No Drupal core
Translation template supplied Yes   Yes Except D5 branch No  

Obviously, in all cases, a "No" actually means: "roll your own", as in all Open Source software.

Features discussion

Features discussion

Criteria Glossary G2 Glossary Glossify
Terms and nodes

Glossary uses Taxonomy to define its terms, allowing definitions to be used as tags for existing nodes.

Since Glossary is taxonomy-based, that opens the range of taxonomy-based modules to work together.

For example, Taxonomy Image may be used to show images for the terms and Taxonomy Delegate may be used to delegate vocabulary maintenance to sub-administrators or editors.

G2 uses Node to store its terms.

This allows access control, attachment uploads, commenting, content tagging, revision control, and integration will the vast number of node-related modules.

Extensibility is directly available from core for G2 content through the extensive core hook system for nodes. Control is available at the individual field level, and includes editor-only information, which is required in publishing situations.

Glossify uses Node to store its terms.

This allows the wide range of contributed modules to add functionality to terms: Adding fields via CCK, defining views with Views, access control, image handling, tagging via taxonomy, etc.

Extensibility is directly available from Drupal core for all glossify entries. Everything that can happen to a node in Drupal can happen to a glossify entry.
Size issues

Glossary is faster than G2 for small glossaries.

While most sites have a smaller glossary than the one G2 was designed for, there are also sites with larger glossaries.

G2 is optimized for large glossaries, not small ones. As such, its requirements do not increase with the number of entries.

At the time of its creation (4.7), supporting a 5000 terms dictionary with glossary.module on a shared hosting plan, was causing severe load issues.

Glossify is not optimized for speed. In fact, for large sites, it's probably a bad idea.
Single vs multiple The ability to handle multiple vocabularies as glossaries gives Glossary additional flexibility G2 is designed around a single glossary by site: multiple glossaries were not necessary to the initial sponsor. More generally, sites maintaining a large glossary are typically centered around it, and won't maintain more than one per site.

While glossify is designed around a single vocabulary (content type), it does allow multiple content types to hold its entries.
Community Glossary has largely been designed by its users. Many, if not most, of its features have been added and refined by the input of the community. G2 has been developed for the specific need of one user and shared afterwards. Its original feature set was designed around that need, and has only been expanded and modified by community input afterwards.

Glossify was designed for a sole purpose by a sole author, and shared afterwards. Expansion and modification of this module will happen via the Drupal community.
Maintenance and support Glossary is actively maintained. There have been performance efforts to make sure it runs as fast as possible. Community support is available, and several Drupal professionals, include some core developers, can support it. G2 is actively maintained. There have been performance efforts to make sure it runs fast even with large glossaries. Community support is available, and commercial-level support is available from its maintainer.

Glossify is feature complete for its original intention and installation. Modifications to the module are outside of its original scope, but welcomed by the maintainer.
Alphabar maintenance Automatic maintenance reduces the need for administrator intervention. Any large glossary will use all available initials from the onset, so administrator intervention is not needed past the initial module configuration, and the processing cost of maintaining it afterwards is useless system load.

Glossify does not provide an alphabar.
Internationalization and localization

Considerable work has been done to make sure that i18n (internationalization) can be effectively used with Glossary.

A translation template is provided.

G2 relies on core for i18n and is expected to work normally on sites with i18n ; its demo site is actually not english. Specific mechanisms have been applied to support non-occidental scripts.

A translation template is provided except for Drupal 5.

The base URL for the glossary pages is admin-defined, thus allowing for translation and module masking.

As glossify entries are simply nodes, glossify relies on Drupal core for i18n and translation services.
Term presentation and links

The Glossary filter locates terms within administrator-selectable content and adds additional HTML to them to show or (optionally) link the term's definition to the end-user as they view the content.

The terms may be marked with a superscript or icon that links to the term or the term may be converted to an "acronym," "abbr," "cite," or "dfn" element with browser help tips. If the Hovertips and Clicktips module is installed, it may be used to provide hovertips. There are also three mechanisms for marking a section of the content to not be filtered. Matching of terms may be selected as whole words or substrings, and may be either case-sensitive or not.

The G2 filter only applies its matching patterns to <dfn> elements in the input.

The terms are wrapped in a valid XHTML link with a title attribute, bearing a G2-specific class to enable pure CSS themeing

Glossify currently supports three types of presentation of terms:

  • Terms are linked to their entries when used in content.
  • Terms and entries can be shown as hovertips (requires the hovertip module).
  • Terms and entries can be shown in a "Reference" section under the node body. This section is exposed to Drupal themeing.

The entries themselves are fully exposed as nodes to the Drupal theme system, and lists can be made via the views module.
Links Terms link to the entire glossary or the individual term, depending on which option the administrator chose. Terms link to the G2 page for the term, which may be either a disambiguation page or the single destination page, depending on whether homonyms exist or not and whether administrators enable the direct link on single matches.

Terms are linked to the individual term.
Glossary display When displaying the entire glossary, there is an alphabar on top, which fills in automatically. The administrator may define his/her own alphabet for those who use some language other than English. The terms are then organized by the first letter of the term's name. Each section may be separated by a CSS-themable separator. At the bottom of the display, if the user has the appropriate permissions, are shortcut links to the vocabulary and module settings pages.

In addition to the individual term pages, G2 includes initial pages, customizable disambiguation (homonyms) pages and a customizable main page.

The main page, may be either a node reference for simplicity or a function name, for easier maintenance in the site module. When not customized, it displays an alphabar on top, identical to the one in the alphabar feature block.

Glossify does not supply a display for the entire glossary. Site administrators and designers can use the views module to create such a display.

Common features

Common features

Glossary and G2 modules work as a Drupal input filter applying to content depending on its input format. These filters are cacheable for performance reasons. Glossify does not provide an input filter. Rather, glossify marks up content on output.

Since the glossary and G2 filter content, the first time a piece of content is shown, there will be a small delay while the filtering is done. The filtered content is then cached, so the next time, the filtering is unnecessary and the delay does not occur. Glossify does not filter, so there is no delay when the content is submitted. Glossify's delay is incurred when content is viewed.

G2 advocacy

G2 advocacy

  • Explicit linking to terms with dfn elements:
    • limits system workload
    • allows invisible marking of entries made of other entries. Think: XML-RPC, points to XML and to RPC with glossary.module and various wiki filters, but can point to "XML-RPC" with G2. Wrapping XML-RPC in quotes is necessary to allow linking to this entry in glossary, but the quotes remain visible, degrading the UI.
    • allows redactor-level choice of:
      • whether to link to an entry: Glossary typically links if the term matches, which is not always meaningful ("and" can be present in a glossary and you don't want "and" to be linked from in all nodes on the site).
      • where to link to an entry: glossary allows only a predefined set of positions (first, last or all matches).
  • Single glossary: multiple glossaries were not necessary to OSInet, which funded development
  • Optimization for large glossaries: this is the need expressed by OSInet, which funded development, to support its 5000+ term glossary of computing, for which glossary.module, even when coupled with flexinode or early CCK to bind blob content to terms, was not really efficient enough
  • Using custom node type (g2_entry in g2.module) allows large definitions, with the complete drupal feature set for nodes. At the time of Drupal 4.7, neither flexinode not CCK were a reasonable choice for a generic module
  • Manual alphabar maintenance: large glossaries will most of the time use all available initials, so the processing cost of maintaining it is not justifiable

Glossary advocacy

Glossary advocacy

  • Customizable
    • Administrator options.
      • Glossary display.
      • Alphabet / Alphabar.
      • Input Formats.
        • Indicator style.
        • Link type.
        • Choice of HTML elements.
        • Term matching flexibility.
    • Liberal CSS usage.
    • Add-on modules.
  • Taxonomy options.
    • Related terms link to each other.
    • Synonyms will filter the same.

Within the glossary display, each term may be followed by a link that will initiate a search for the term, if the search module is enabled. For those who have the proper permission, there will also be a link to edit the term itself.

The type of glossary indicator that is used is specified for each input format, so, for example, "Filtered HTML" may use a superscript type of indicator, while "Full HTML" may use a hovertip. Additionally, each input format also selects which vocabularies are to be used. So one may, again for example, specify that "Filtered HTML" filter for Bible verses, while "Full HTML" filters for technical terms.

Using terms (glossary.module) allows definitions to be bound to custom nodes instead of being nodes on their own

Glossify advocacy

Glossify advocacy

Glossify aims at simplicity. Its code is small, its options are few, and its job is straightforward. Glossify looks at content before it is output, finding and marking up any content that is a title of another piece of content, and links the title to the entry. It does not provide an input filter, nor does it generate a landing page of entries.

Since glossify uses nodes as its entries, the vast customization that Drupal core and contrib offers to nodes are available to glossify entries. They are not limited to entry and definition pairs, but can include other fields via the Content Construction Kit. Lists and blocks can be created with Views. Entries can be classified with taxonomy; they can be themed with PHPtemplate or other theming options.

Glossify has options to limit the content types used for entries and the content types it will look through, and has three different display options for showing what terms have been referenced in the content:

  • The title can simply be linked to the entry. This is wiki-like. The link includes a class for styling via CSS.
  • The entry can be shown via a hovertip, if the appropriate module is available. These can be themed via Drupal's theming mechanism.
  • A "referenced terms" area can appear underneath the main content. This section is available for theming via Drupal's theming mechanism.

g2/choosing_next.txt · Last modified: 2023/05/27 15:24 by fgm