You are here: Home » About » Technology » Connexions Architecture » Editing Environment

Editing Environment

The Connexions editing environment provides a place for users to collaborate on the creation and management of content in the repository.

Work Areas
The editing environment provides persistent work areas in which to develop and manage content. Each work area supports basic operations such as object creation, cut/copy/paste, and deletion of both content objects and other files. There are two kinds of work areas provided:
My Workspace
Each user has a private folder to store local copies of content that he or she is working on. Changes made to the local copy do not appear in the repository until the content is published. My Workspace is accessible only by its owner.
Workgroup
Workgroups are functionally identical to My Workspace for managing content, but are owned and accessible by a group of users rather than by an individual. The workgroup and its contents are communal property; each member has the same rights to manage both the workgroup's contents and its membership list.
Create new content
In any work area, a user can create new content objects to prepare for publication in the repository. Newly created objects do not appear in the repository until they are published.
Checkout a working copy
Any user may checkout a local copy of a published piece of content into a work area and make modifications to it. These changes will not be visible outside the work area until the content is published as a new version. Note: permission to edit a content in a work area does not imply permission to publish the changes. Users who do not have permission to publish may either suggest changes or derive a copy (see below).
Role Requests
Some of the metadata fields on content objects are lists of people who have a specific role for that content, such as author or maintainer. When editing content, a user cannot change another person's roles without that person's agreement. Role change requests remain in a pending state until the other party logs in and approves or rejects them. Note: a content object cannot be published while any role requests for that object remain pending.
Suggest changes
Any user may make local modifications of published content and then send the changes as a suggestion to the maintainers of that content. This is equivalent to the idea of submitting a patch in software development. Once suggested changes to a specific piece of content have been submitted, the maintainers of that content can view the pending changes and will have the opportunity to accept or reject them. Accepting the changes merely means applying them to a local copy of the content in a work area. Note: The changes will not appear in the repository until the maintainer publishes a new version from the local copy.
Derive copy
If a user wishes to take a piece of content in a different direction than its original authors, he or she may wish to derive a new work from the original. This is equivalent to the idea of forking in software development. It is only allowed if the license of the original work permits derivative works.
Edit-In-Place
As an alternative to the process of checking out content to a work area, maintainers may edit module text in place through the web. This allows for quick, small textual changes such as correcting typos.