lenya-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Lenya Wiki] Update of "TerminologyForDocumentation" by JörnNettingsmeier
Date Tue, 03 Jan 2006 23:41:32 GMT
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/TerminologyForDocumentation

------------------------------------------------------------------------------
- This page is intended to clear up some terminology for use in new documentation of the Lenya
directory tree. It contains proposed usages of many technical terms and their definitions.
Please extend and review. Many documenters are not coders, but must they rely on coders to
verify that the language in the docs is consistent with internal usage among developers and
in the code. Hence this page. 
+ This page is intended to clear up some terminology for use in new documentation of the Lenya
directory tree. It contains proposed usages of many technical terms and short definitions.

+ 
+  ''Please extend and review. Many documenters are not coders, but must they rely on coders
to verify that the language in the docs is consistent with internal usage among developers
and in the code. Hence this page.'' 
  
   ''This is an initial draft that has not seen much discussion on the lists, except for one
comment. Developers, please look through this and suggest corrections or sign it off below
so that people see it's been verified.'' --JörnNettingsmeier
+ 
+  ''Oh drat, instead of the stupid page title this should have been "Glossary" right from
the start. FIXME: move page.''
  
  == Publications ==
  
@@ -19, +23 @@

  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".

+ 
- The creation of a new child publication from a template is called '''instantiation'''. 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. 
+ 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.
  
  == Resource Types ==
  
- A ''resource type'' describes what a page in a Lenya publication can contain and how it
behaves. It consists of a Relax-NG schema that defines the XML grammar for pages, and modules
that govern the behaviour of the pages (both in authoring and live). (FIXME: probably incomplete
and inaccurate)
+ From [http://lenya.apache.org/1_4/reference/resource-types.html]: 
+ 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'', ''links''
+ The default publication contains the resource types ''xhtml'', ''homepage'', ''OpenDocument'',
''CForms'' and ''links''.
  
  == Areas ==
  
- 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).
+ 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'''.
  
- to be defined:
+ In [http://lenya.apache.org/1_4/concepts/authoring_live.html] you will find term '''mode'''
instead of "area" to describe the same concept.
  
- modules, source factory (=uri resolver?, =protocol specifier?) (cocoon://, fallback://,
template:// (is this one implemented?), context://, any others?), context
+ == Roles/groups ==
  
+ (FIXME: are groups analog to roles? If not, explain.)
+ 
+ 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.
+ 
+ == 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
+  * a resource type (e.g., docbook module)
+  * a repository implementation (e.g., jdbc module)
+  * a collection of XSLTs (e.g., content2svg module)
+ 
+ See [http://lenya.apache.org/1_4/reference/modules/index.html].
+ 
+ == to do ==
+ 
+ === more terms ===
+  * sitemap
+  * 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)
+ 
+ (FIXME: find out about different syntaxes, e.g. {fallback:....} - when do I use which?)
+ 
+  * context
+ 
+ === misc ===
+  * cross-reference each term to the appropriate docs
+ 
+ == new terms used in this section: ==
+ 
+  * property (any file within a publication)
+  * child publication (we have instance, but i think that's too OOP)
+  * workflow action
+ 
+ Are there better, already established terms for these concepts? If so, let's use them instead.
+ 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Mime
View raw message