User Tools

Site Tools


g2:choosing

This is an old revision of the document!


Back to G2 main

Choosing a glossary-type module

G2 is not intended as a direct replacement for the glossary module already available with drupal for quite some time now. It was designed for slightly different needs, and this page is here to help you choose which module you should probably be using, or if you should really write your own. Lexicon has been evolved from glossary to accomodate yet another set of requirements, and glossify started with needs similar to glossary, but evolved to a much more diverse set of features; only those relevant to glossaries should be listed here.

Feature Glossary G2 Glossify Lexicon Refactoring
Drupal-related
Drupal 7.x No No(t yet) No(t yet) Yes Yes
Drupal 6.x Yes Yes Yes Yes No
Drupal 5.x Yes Yes Yes No No
Drupal 4.7.x Yes Yes No No No
Drupal 4.6.x Yes No No No No
AJAX No Some autocompletion
Storage terms nodes, single content type any entity
Services provided
multiple glossaries on one site Yes No Yes
RSS feeds on entries core No
RSS feeds on additional vocabularies No core core
classify entries No core taxonomy core fields
commenting on entries No core core, only on node storage
private editorial information No Yes core fields
alphabar maintenance automatic manual
content filtering, automatic Yes No Yes
content filtering, explicit No Yes, dfn element Yes, custom element
feature blocks No alphabar
latest
top
random
word of the day
remote glossaries No Yes, limited Yes
Security core core
XML-RPC access control
XML-RPC throttling
3rd party integration
Quality Agent No No Yes
Views: basic core core + specific core + specific
Views: default views No No Yes
Wikipedia No No Yes, with i18n
Zeitgeist No No Yes
Performance
memory needs/number of entries proportional constant
speed on small glossaries faster slower
speed on large glossaries slower with size remains constant
Themeing
- search form Yes core
- node overview Yes core
- definition fields n.a. Yes core fields
- each feature block n.a. Yes
Implementation Templates Theme functions Templates
Developer features
XML-RPC API No alphabar
latest
top
random
word of the day
UI module separate from Data API No No Yes

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

Rationale for G2 specificities

  • 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 to bind blob content to terms, is not really efficient enough.
  • Single glossary: multiple glossaries were not necessary to OSInet, which funded development
  • 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 always 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)
  • nodes vs terms: this is the most salient difference.
  • Using custom nodes (g2_entry in g2.module) allows large definitions, with the complete drupal feature set for nodes,
  • Using terms (glossary.module) allows definitions to be bound to custom nodes instead of being nodes on their own
  • Alphabar maintenance: large glossaries will most of the time use all available initials, so the processing cost of maintaining it is not justifiable
g2/choosing.1294823785.txt.gz · Last modified: 2011/01/12 10:16 by fgm