|Kongregate Registration for Free Flash Games and Chat with solprovider|
"Index" to refer to an easily configurable internal data structure used to allow multiple "structures", both flat and hierarchical.
Flat Indexes return all Resources on one level. Hierarchical Indexes return Resources listed under their Parent in a specific Structure from the RelationsTable. Selections can include only Resources of a certain ResourceType(s), DocumentType(s), or AssetTypes. Indexes are configured using XML to specify the Type (Flat or Hierarchical), Structure (if Hierarchical), Selection (additional limits), Sort (formula for determing the order), and included Items (for use by the calling Module). Indexes are configured in Modules, but stored in the Publication.
Configuration looks like:
If structure is missing or empty, the Index will be flat.
Each Resource matching the filters is added to the results as a
Elements and Properties are matched against every Resource. If the specified item exists, it is added to the results.
For performance, the publication checks the existing Indexes for an exact match when adding a new one. If the definition already exists, then the new Index's name is added as an alias for the existing Index. Example: The "RSS" module uses the Index "RSS", but the definition matches an existing Index "LastCreatedFirst". This allows Modules to name their Indexes with the Module name, without creating and maintaining duplicate Indexes.
Examples of Indexes:
- standard hierarchical menu: all Documents under parents.
- alternate hierarchical menus (only certain DocTypes, or by Author then last update)
- flat alphabetical by Title
- flat by DocType, with a secondary sort by Title or last update.
- flat by CreatedDate or LastModified (useful for the RSS Module)
- flat for "submitted but waiting for approval." (useful for maintaining the Publication)
Notice the "internal" in the definition. The only people aware of Indexes would be:
- Programmers of core that implement the feature.
- Developers of Modules that concern multiple Resources.
To clarify, the bulk of understanding "Index" falls to the programmers of core implementing the feature. The "live" Module is only concerned with one Resource, so the developer does not need to understand "Index". The "live" Module aggregates the result of the "menu" Module. The "menu" Module creates a list of multiple Resources, so configures a hierarchical Index. The developer of the "menu" Module only needs to understand that properly using XML to configure an "Index" allows using the following line to generate XML about multiple documents:
The SitetreeGenerator does the work; the developer looks at the resulting XML to see if the Index configuration is correct, then continues writing the Module (probably adding XSL transformations.)
Indexes would also be used internally to translate between the ID (or URL) (/section/category/documentid) and the UNID (unique identifier of the Resource in the flat storage of Content) used to retrieve a Resource. Again, use of the Index is transparent to everybody except the core programmers implementing the feature.
I think Indexes should be built into the core as part of the migration to using JCR. I hope it can be done by adding the RelationsTable, the normal "live" hierarchical Index, the SitetreeGenerator, and changing a few Document functions to use the new technology. Support for automatically adding additional Indexes can be added later. This work is important because aggregating Content using the XPathDirectoryGenerator will be impossible after the migration to JCR.