Dear Wiki user, You have subscribed to a wiki page or wiki category on "Lenya Wiki" for change notification.
The following page has been changed by JörnNettingsmeier: http://wiki.apache.org/lenya/Glossary ------------------------------------------------------------------------------ It is aimed at new Lenya users looking for a short primer, at proficient users in need of a handy reference and at developers and documentation writers who need a quick refresher in order to maintain consistent usage of technical terms in their code comments and docs. - ''Developers, please extend and review, to verify that the language in the docs is consistent with internal usage among developers and in the code. Some stuff is taken from the official docs and should be ok, but other parts may contain errors or misconceptions.'' - '''This page deals with Lenya 1.4 only. Some if not most concepts will also apply to Lenya 1.2.x, but users of this version had better refer to the (quite extensive) 1.2 docs. For a concise overview of 1.2 terms, see also ["CMSTerminology"] (includes a terminology cross-reference between different CMS systems).''' - == Publications == + ---- - Websites created in Lenya are called '''publications'''. Some people feel this term is unfortunate (why not just call them "sites", but for now we're stuck with it. + access control:: - A Lenya installation can contain more than one publication. Publications can either be fully independent, or they can share common properties. See '''Templating''' below. + area:: Lenya differenciates between two areas: '''authoring''' (which is what you use while you edit your pages) and '''live''' (which is what the visitors of your website will see). Both areas share many properties (notably the presentation of the content), but can have additional properties of their own (an obvious example are the editing menus in the authoring area). Live and authoring can have different content. + A page moves from authoring to live and back according to '''workflows'''. - See also [http://lenya.apache.org/1_4/concepts/publication.html]. + In the docs you will sometimes find term '''mode''' instead of "area" to describe the same concept. - == Publication Templating == + See also [http://lenya.apache.org/1_4/concepts/authoring_live.html]. - Every publication can be used as a '''template''' for new publications, producing '''derived publications''' or '''child publications'''. + asset:: + + context:: - Provided you use the "New Publication" usecase, all publications will ultimately be based on the '''default publication''' that comes with Lenya. + group:: + mode:: A synonym for '''=>Area''' - Templating is implemented using the '''fallback''' mechanism, a lenya-specific uri resolver that can be applied to any uri reference in xml files by using ''fallback://'' as a protocol specifier. If this is done consistently, publications can share arbitrary '''properties''' (i.e. xslt files, configuration files, user/group account files, sample pages, resource types etc.) from their template or from the default publication. - ''The fallback mechanism operates on a file level. Thus it can only be applied to whole files (not parts thereof), and only if those files are referenced by URIs in configuration files.'' - The creation of a new child publication from a template is called '''instantiation'''. Therefore, you will sometimes find the term "'''instance''' of template X" instead of "child of X". - - Child publications can use features of their template(s) in two ways: by '''copying''' files from the template during instantiation, or by '''referencing''' those files. - ''Note from AndreasHartmann: better avoid the term "inherit", since it is used in a more general way in OOP, and might cause misconceptions.'' - - ''Note from JörnNettingsmeier: perhaps then the term "instance" should also be avoided? It's currently used in [http://lenya.apache.org/1_4/reference/publication-templating/index.html].'' - - '''Copying''' severs the link between child and template - later changes to the template will not affect the child. - '''Referencing''' implies that all changes to the template will immediately affect the child as well, since the child uses the template's property. - - See also [http://lenya.apache.org/1_4/reference/publication-templating/index.html]. - - == Resource Types == - - A '''resource type''' defines a certain XML source format, together with processing options. It typically consists of - * an XML structure definition (e.g., Relax NG) - * some presentation pipelines, - * some presentation XSLT stylesheets, - * usecases to manipulate documents. - The default publication contains the resource types ''xhtml'', ''homepage'', ''OpenDocument'', ''CForms'' and ''links''. - - See also [http://lenya.apache.org/1_4/reference/resource-types.html]. - - == Area == - - Lenya differenciates between two areas: '''authoring''' (which is what you use while you edit your pages) and '''live''' (which is what the visitors of your website will see). Both areas share many properties (notably the presentation of the content), but can have additional properties of their own (an obvious example are the editing menus in the authoring area). Live and authoring can have different content. - A page moves from authoring to live and back according to '''workflows'''. - - In the docs you will sometimes find term '''mode''' instead of "area" to describe the same concept. - - See also [http://lenya.apache.org/1_4/concepts/authoring_live.html]. - - == Mode == - - See "Area" - - == Roles == - - By default, Lenya defines three basic roles that a lenya user can have. - An '''admin''' can control all aspects of a publication and create, delete or modify users and groups. An '''editor''' can modify and create new content, but cannot publish it; for this, s/he hands the work to a '''reviewer''', who does the final check and decides whether the page can go live. - - You can define new roles and workflows. - - Do not confuse roles and groups. OverviewAccessControl has a good explanation of how different they are. - - == Workflow == - - '''Workflows''' describe a sequence of actions to accomplish a task. For instance, in order to move a page from the authoring to the live area, an editor must '''submit''' it. A reviewer can then '''reject''' it (it gets sent back to the editor for some more polishing) or '''publish''' it, in which case the page moves to the live area. - - To move a page back from live to authoring, a reviewer must '''deactivate''' it. Afterwards, it can either be re-published or '''deleted'''. - - Workflow actions are implemented with '''usecases'''. Moreover, "usecase" is often used as a synonym for the rather kludgy "workflow action". - - You can define new workflow actions and rules for changing between states, but this requires custom java code. - - == Modules == - - Modules are packages providing a certain set of resources or functionality, such as + module:: Packages providing a certain set of resources or functionality, such as * a resource type (e.g., docbook module) * a repository implementation (e.g., jdbc module) * a collection of XSLTs (e.g., content2svg module) - See also [http://lenya.apache.org/1_4/reference/modules/index.html]. + see also [http://lenya.apache.org/1_4/reference/modules/index.html]. + + publication:: A website created with Lenya. A Lenya installation can contain more than one publication. Publications can either be fully independent, or they can share common properties by '''=>publication templating'''. + + see also [http://lenya.apache.org/1_4/concepts/publication.html] + + ''[Some people feel this term is unfortunate (why not just call it a "site"?), but for now we're stuck with it.]'' + + publication templating:: A mechanism for sharing properties between publications. Every publication can be used as a '''template''' for new publications, producing '''derived publications''' or '''child publications'''. Provided you use the "New Publication" usecase, all publications will ultimately be based on the '''default publication''' that comes with Lenya. + + Templating is implemented using the '''fallback''' mechanism, a lenya-specific uri resolver that can be applied to any uri reference in xml files by using ''fallback://'' as a protocol specifier. If this is done consistently, publications can share arbitrary '''properties''' (i.e. xslt files, configuration files, user/group account files, sample pages, resource types etc.) from their template or from the default publication. + ''The fallback mechanism operates on a file level. Thus it can only be applied to whole files (not parts thereof), and only if those files are referenced by URIs in configuration files.'' + The creation of a new child publication from a template is called '''instantiation'''. Therefore, you will sometimes find the term "'''instance''' of template X" instead of "child of X". + + Child publications can use features of their template(s) in two ways: by '''copying''' files from the template during instantiation, or by '''referencing''' those files. + '''Copying''' severs the link between child and template - later changes to the template will not affect the child. + '''Referencing''' implies that all changes to the template will immediately affect the child as well, since the child uses the template's property. + + see also [http://lenya.apache.org/1_4/reference/publication-templating/index.html] + + resource type: An XML source format, together with processing options. It typically consists of + * an XML structure definition (e.g., Relax NG) + * some presentation pipelines, + * some presentation XSLT stylesheets, + * usecases to manipulate documents. + The default publication contains the resource types ''xhtml'', ''homepage'', ''OpenDocument'', ''CForms'' and ''links''. + + see also [http://lenya.apache.org/1_4/reference/resource-types.html] + + role: By default, Lenya defines three basic roles that a lenya user can have. An '''admin''' can control all aspects of a publication and create, delete or modify users and groups. An '''editor''' can modify and create new content, but cannot publish it; for this, s/he hands the work to a '''reviewer''', who does the final check and decides whether the page can go live. + You can define custom roles and workflows. + + Do not confuse roles and groups. OverviewAccessControl has a good explanation of how different they are. + + sitemap:: + + source factory:: + + usecase:: + + user:: + + workflow:: A sequence of actions necessary to accomplish a task. For instance, in order to move a page from the authoring to the live area, an editor must '''submit''' it. A reviewer can then '''reject''' it (it gets sent back to the editor for some more polishing) or '''publish''' it, in which case the page moves to the live area. + To move a page back from live to authoring, a reviewer must '''deactivate''' it. Afterwards, it can either be re-published or '''deleted'''. + + Workflow actions are implemented with '''=>usecases'''. Moreover, "usecase" is often used as a synonym for the rather kludgy "workflow action". + + You can define new workflow actions and rules for changing between states, but this requires custom java code. == to do == === more terms === - * sitemap * source factory (is this the same as a uri resolver? or a protocol specifier?) * cocoon:// * fallback:// @@ -105, +94 @@ (FIXME: find out about different syntaxes, e.g. {fallback:....} - when do I use which?) - * context - * user - * group - * usecase - === misc === * cross-reference each term to the appropriate docs * keep each definition short and sweet. perhaps the more verbose explanations can be merged into the docs if it makes them easier to understand? + * maintain alphabetic order == new terms used in this section: == --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
