Solprovider Lenya Kongregate Registration for Free Flash Games and Chat with solprovider


The Introduction explains how the pieces fit together. These are my definitions. They are reasonably accurate for Lenya 1.2.
The definitions for Lenya 1.4 assume my idealized version of Lenya.
Maybe they should be marked 1.5. Some of the concepts in the Glossary are quite different from the current suggestions, but the terms are all easily understood and holistically consistent. Some of them (see "RelationsTable") will require enough work that they should be pushed to 1.5.

All defintions for Modules have been moved to the Modules page.

[1.2] Document storage was designed so workflow moved the Document files between "Area" directories under "Content". This workflow directory name was used in URLs to upset most people.
[1.4] This was a silly concept easily replaced by either changing filenames in Lenya 1.2, or adding a Workflow Status field in Lenya 1.4. The "Area" part of the URL will identify the Module to be used for processing.

[1.2] The CMS GUI name for an uploaded file stored as a child of a Document. Assets were associated with a Document. This caused major headaches for users because the DocumentID of the Parent Document was required in the URL to link to the Asset.
[1.4] Any non-XML Resource. Stored in Content as a Resource.

AssetType: Property of an Asset specifying the format of the data. Useful for use with AssetModules.

Child: Any Node contained by the current Node.

[1.2] The directory storing Documents. It was divided into "Areas" which contained Documents in hierarchical structure with a static Sitetree.
[1.4] The parent Node for Documents and Assets.

ContentItem: Alternative name for Resource.

ContentType: See ResourceType.

Document: An XML Document.
[1.4] The major difference from Assets is that Documents can be processed by XSL statements (map:translate). It is impossible to do XSL Transformations on non-XML data (the definition of an Asset).

DocumentID: The property of a Resource specifying its human-readable name.

DocumentType: Property of a Document specifying the DTD and which Module normally transforms the XML to XHTML. The default is "xhtml". See Type Module.

DocumentUNID: The property of a Resource specifying its unique internal name.

1. Plug-in software (Modules in 1.4) for editing Documents.
2. A person who uses such software to input and maintain Documents.

i18n: Internationalization functions. Non-content Modules use i18n to provide translation to multiple languages.
[1.2] i18n files are stored at the Global and Publication levels in the Resources directory.
[1.4] i18n files are stored in Modules at the Global, Template, and Publication levels. Modules can specify to use i18n files from other Modules (if the other Module exists.) ?Should there be i18n files used by multiple Modules?
The search for an i18n key should be:
This Module
Additional Modules this Module specifies
Repeat for the Template Module if inherited from a Template.
Repeat inheritance check through Global Module or no more inheritance.

Index: [1.4] A data structure used for selecting and sorting Resources. See Indexes.

Module: [1.4] A functional component of Lenya. See Modules.

[1.2] A DIV used by XSL (or the code that creates one) to provide access to Documents in a structured manner: menus, breadcrumbs, website maps. The Navigation framework uses XSL to transform the Sitetree to a DIV with a specific ID to be aggregated with other Navigation Elements and Documents. The Sitetree is used with:
<map:generate src="pubs/{1}/content/{2}/sitetree.xml"/>
[1.4] See NavigationModule.

Node: Standard term for an element of a data structure. An Element in XML. A data unit in JCR (Jackrabbit).

Orphan: Any Node that has no Parent specified. By definition, the root Node is an Orphan. For Resources, the homepage Document (default id="index") is an Orphan. Orphan Resources may also be created by not specifying a Parent, or by deleting the Parent of other Resources. Orphans appear in flat Indexes that select them. An special Orphans Index may be useful for maintaining Publications.

Page: The response sent to a visitor in response to a Request, typically HTML. Pages are generated by PageModules. A "Page" is not something storable in Lenya (except in a non-functional cache where the HTML and other content generated by Lenya is stored for performance.) A Page can include links to Assets and other Pages.

Parent: A Node containing the current Node.
[1.2] Each Document specifes one Parent.
[1.4] Each Resource can specify one or more Parents. The Relationship Tables store the relationships for performance.

PDF: Adobe's Portable Document Format
[1.2] PDFs may be added as Assets, or generated by XMAPs and Usecases.
[1.4] PDFs may be Assets, or generated by Modules.
A Module may transform a Document (or multiple Documents and possibly Assets) into a PDF. The result could be saved in Lenya as an Asset, but performance could be improved without creating another static resource by saving the results in the non-functional cache. The URL of the PDF would be the URL of the PDF-creating Module and any parameters it requires to create the specific PDF.
If a PDF is uploaded, then it is an Asset.
If the PDF is dynamically generated, then it is accessed though a Module:
The parameter(s) could be:
- a single Document identifier that is transformed to PDF using XSL.
- several resources (Document and Assets) sequentially added to PDF.
- a key identifying a configuration document.
- anything else imaginable.

Publication: Collection of data and special processing instructions.
[1.2] Publications contained all content, configuration, and processing instructions, but could inherit from Global using special syntax.
[1.4] Publications contain all content. Configuration and Modules (processing instructions) automatically inherit from Templates and Global, but may be overriden in the Publication.

RelationsTable: [1.4] A data structure to maintain the Parent-Child relationships. See RelationsTable.

Request: Any input sent by a visitor.

Resource: Superclass for Documents and Assets. It specifies the framework for Translations and Revisions, including Workflow.

[1.2]: The directory for static Assets. The directory was also overloaded for various plug-ins.
[1.4]: Not used. See ContentItem and Module.

ResourceType: Specifies if a Resource is a Document or an Asset.

Revision: For each Resource/Translation, every version is saved for history and rollback as a Revision Node.

[1.2] Poor.
[1.4] Security is handled at several levels.
- If the current visitor does not have access to the requested Resource, Sorry is returned.
- The SitetreeGenerator will not include any Resources for which the current visitor does not have access.
- Search does not include any Resources for which the current visitor does not have access. (Search may be refactored as a Generator similar to the SitetreeGenerator. The major change is using a SearchEngine such as Lucene to dynamically create the Index rather than using a statically configured Index.)

Site: Shorthand for Website. See Website.

1. A listing of selected Resources on a Website or Publication.
2. Cocoon: An XMAP file. See XMAP.

[1.2] A static XML file supposed to contain the hierarchy of Documents, along with the Navigation name and Languages.
[1.4] Results of the SitetreeGenerator

SitetreeGenerator: Uses an Index and Content to dynamically generate XML for Navigation Elements. It is used in XMAPs with:
<map:generate type="sitetree" publication="{pubid}" index="{desiredIndex}"/>

Structure: A field in the RelationsTable for categorizing the relations. See RelationsTable.

Sorry: The response to requests for missing and unauthorized content. The Node is configured as a DIV with the ID of "body". The HTML response code is changed to an error when sending the Sorry page, but that can be overriden by the Module that receives the Sorry. The default Sorry is:
<div id="body">The requested content does not exist or you are not authorized to receive it. You may want to login.</div>

Template: A base for creating new Publications that use the same functionality. Templates can be based on other Templates. Each Templates can specify which GlobalModules are used, and override the Module functionality in the normal manner. Templates are created and edited as a Publcation, but cannot be used as a Publication. A Publication created from a Template inherits all the functionality, and copies the configuration including the default Resources.

[1.4] Node under Resource specifying the language, and containing Revisions. (Alternatives: Language Version, Document Language Node)

[1.2] Special processing instructions requested by appending "?lenya.usecase=UsecaseID" to the Request URL. This provides alternate entry points to a Publication. The Usecase XMAP is separate from Publication and other Usecase XMAPs for cleaner code.
[1.4] Deprecated because the URL hack was silly. See Modules.

[1.4] "Version" is used by JCR for versioning, so repository Nodes have "versions", but "Documents" have "Revisions".

Website: A collection of Publications and other material accessed through a single Internet domain.

Workflow: The process a Resource must follow. Typically, "Draft" (Unpublishable), "Ready" (Publishable), "Live" (Currently Published), "Obsolete" (Published but Replaced)

XMAP: An XML file containing processing instructions for Cocoon. The Cocoon Project calls them "Sitemaps" to confuse people.

<< Terminology RulesProtocols >>

Contact Solprovider
Paul Ercolino