Versions Compared

Old Version 2

changes.mady.by.user ASF Infrabot

Saved on

compared with

New Version 3

changes.mady.by.user ASF Infrabot

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

...

  • policy 1: user John has the role "edit" on the URL "/news"
  • policy 2: IP range 182.12.4.122/255.255.0.0 has the role "review" on the URL "/news"
    If John logs in from a machine in this IP range, he has the roles "edit" and "review" on the URL "/news".
    protocol
    indent
    \\
 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:
      • file:// - read a file from disk, using the operating system's path as the URI
      • cocoon:// - request a resource from the cocoon servlet (handled by the sitemap pipelines, so this need not exist as an actual file)
      • context:// - request a file from disk, using the webapp context directory as root
    • Lenya-specific:
      • lenya-document:// - request a document from the Lenya storage by its =>UUID and optionally language and revision (i.e. independent of its current location in the site tree)
      • site:// - request a document based on its sitetree path
      • fallback:// - request a file using the =>fallback mechanism
      • fallback-template:// - dito, but skip the current publication and start looking in its template instead
      • aggregate-fallback:// - concatenate the content of a file in this publication with the contents in all ancestors
        Protocols are implemented using =>source factories.

      • Wiki Markup
        {{lenya://}} - request a file from disk (same as context:/, but the returned source is a [RepositorySource] with additional features) FIXME: is that correct?
\\
 _(see also http://lenya.apache.org/1_4/reference/protocols/index.html)_
\\
 _\[Needs proofreading and completion. Lenya-Metadata factory is missing.\]_
\\
 *publication*
\\

        indent
        
\\
 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*.
\\

        Wiki Markup
        \\
 _(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*
\\

        indent
        
\\
 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)
        publish
        indent
        
\\
 see *=>workflow*
\\

        resource
        indent
        
\\
 A generic term in need of clarification that can mean almost anything.
\\

        resource type
        indent
        
\\
 An XML source format for Lenya *=>documents*, 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)
      review
      indent
      \\
 The act of proof-reading a *=>submit*ted document and deciding whether to *=>publish* or to *=>reject* it. See also: *=>workflow*.
\\

      revision control
      indent
      \\
 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 (JCR development is currently stalled, though).
\\

      (see also JcrConfiguration)
      role
      indent
      \\
 The capabilities and privileges of an *=>identity*. *Policies* are used to determine the roles of an identity for acertain URL. Roles are used to define conditions for *=>workflow* transitions, and to restrict access to *=>usecases*. The default publication defines four 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. The *visitor* is just allowed to view pages.
\\
      You can define custom roles and workflows.
      Roles are frequently assigned via =>group membership, but do not confuse roles and groups. OverviewAccessControl has a good explanation of how different they are.

...