Usually, the Studio framework will already have taken care of the login when your code is invoked.
In special cases, for example if you are not in CoreMedia Studio,
you can use the static method com.coremedia.cap.Cap.prepare(Function) to create
a connection to the remote server. The URL of the CMS remote service to use is read from the
global variable coremediaRemoteServiceUri. The prepare method
calls the callback function when the connection has been established, passing
a com.coremedia.cap.common.CapConnection as the single argument.
This connection is not yet bound to a user, but it provides the method
getLoginService(). On the returned
com.coremedia.cap.common.LoginService you can call the login(String,
String, String, Function) method to authenticate the current user, which enables
access to other services of the connection.
Once a connection is established, the current session is stored under the key
session in the application scope bean (obtainable from the current
editorContext instance). The session provides access to the current user and
back to the connection.
The methods getContentRepository(), getUserRepository(),
and getWorkflowRepository() of the
connection return objects of type com.coremedia.cap.content.ContentRepository,
com.coremedia.cap.user.UserRepository,
and com.coremedia.cap.workflow.WorkflowRepository, respectively. These repositories
serve the same purpose as the identically named objects of the
Unified API. However, the supported functionality is
limited to the use cases required for content editing.
The ContentRepository provides access to the PublicationService
and the content AccessControl
through the method getPublicationService() and
getAccessControl(), respectively.
Unlike the Unified API, approval operations using the publication service also approve all folders on the path to a content. Publication is very similar to the Unified API counterpart, but withdrawals are performed in a single step without the need to successively set a mark, approve it, and publish the withdrawal.
The AccessControl class in the package
com.coremedia.cap.content.authorization allows you to check whether
certain operations on contents are permitted for the current user.
Some methods like mayMove() and mayCreate() are provided
for special cases, but most checks are made using the method
mayPerform, which takes a Right
enumeration value to indicate the intended operation.
All these methods track the dependencies and can be used from within
a FunctionValueExpression, even though you cannot register
change listeners directly.
The WorkflowRepository provides access to the WorklistService
and the workflow AccessControl
through the method getWorklistService() and
getAccessControl(), respectively.
The WorklistService corresponds closely to the WorklistService of the
Unified API. It provides access to all
user-specific lists, but not the administration lists. In particular,
you can retrieve the list of process definition that
the current user may instantiate,
the processes the user has created, but not started,
the processes the user has created and started,
the offered task and the accepted tasks. You can also obtain lists
of tasks that encountered problems during their execution.
All these methods track the dependencies and can be used from within
a FunctionValueExpression, even though you cannot register
change listeners directly.
The AccessControl class in the package
com.coremedia.cap.workflow.authorization allows you to check whether
certain operations on workflow objects are permitted for the current user.
The methods match the methods defined in the Unified API.
While the rights are being retrieved, the methods will return undefined.
Afterwards a Boolean value is answered.
Note, however, that no changes of rights are propagated to the client.
This is not normally a problem, because the built-in rights policies depend
on the current user, only, and not on the workflow state.
 |  |  |
 |