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 ------------------------------------------------------------------------------ ---- - access control:: + access control:: The functionality needed to restrict and control who may edit, publish or visit the content of a Lenya publication. + + ''(see also OverviewAuthenticationAndAuthorization)'' archive:: see '''=>area''' @@ -66, +68 @@ navigation:: + protocol:: A specifier used in URIs to define where the content comes from and in which format. The most famous is likely '''http://'''. In Lenya publication sitemaps, you will find the following protocols: + * from Cocoon: + ** cocoon:// + ** context:// + * Lenya-specific: + ** lenya:// + ** lenyadoc:// + ** fallback:// + ** fallback-template:// + Protocols are implemented using '''=>Source factories'''. + + ''(see also http://lenya.apache.org/1_4/reference/protocols/index.html)'' + + ''[Needs proofreading and completion. Lenya-Metadata factory is missing.]'' + 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 via '''=>publication templating'''. ''(see also [http://lenya.apache.org/1_4/concepts/publication.html])'' @@ -98, +115 @@ review:: The act of proof-reading a '''=>submit'''ted document and deciding whether to '''=>publish''' or to '''=>reject''' it. See also: '''=>workflow'''. - revision control:: + revision control:: The ability to preserve past states of documents, roll back to them as needed and show the differences between revisions. Lenya currently has a file-based revision control mechanism and an experimental new one based on the JackRabbit implementation of the JCR (or Java Content Repository) API. role:: The capabilities and privileges of a user as part of a '''=>workflow'''. 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. @@ -107, +124 @@ site:: A synonym for '''=>publication'''. - sitemap:: + sitemap:: A concept from Apache Cocoon; an xml file that governs how page requests are handled, i.e. where the data comes from and how it has to be transformed and presented to the user. + + ''(see also OverviewSitemapStructure and [http://lenya.apache.org/1_4/reference/lenya-sitemaps.html])'' site tree:: The tree-representation of the hierarchical relationship of documents within a site. Currently implemented as an XML file under <pubname>/content/sitetree.xml. site tree node:: A particular document entry within the site tree. - source factory:: + source factory:: A piece of Java code implementing a '''=>protocol'''. Used in sitemaps. submit:: The act of passing on an '''=>edit'''ed document to '''=>review'''. See also: '''=>workflow'''. usecase:: (1) A user-triggered action. (2) The corresponding code to implement it. - ''(see also http://lenya.apache.org/1_4/reference/usecase-framework/index.html)'' + ''(see also [http://lenya.apache.org/1_4/reference/usecase-framework/index.html])'' user:: @@ -132, +151 @@ You can define new workflow transitions and rules for changing between states, but this requires custom java code. - == to do == + ---- + == To do == - === more terms === - * source factory (is this the same as a uri resolver? or a protocol specifier?) - * cocoon:// - * fallback:// - * template:// (has this one been implemented yet?) - * context:// - * lenya:// - (FIXME: divide into cocoon and lenya-specific ones + give a quick explanation of what they do) + === New terms === - (FIXME: find out about different syntaxes, e.g. {fallback:....} - when do I use which?) + === Misc === - === 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: == + == New terms coined for this section == * property (any file within a publication) * child publication (we have instance, but i think that's too OOP) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
