Obsolete Pages{{Obsolete}}
The official documentation is at: http://docs.alfresco.com
{{AVMWarning}}
AVM
This page describes work in progress on providing a WCM Services Layer. It is made up of content that is highly speculative and undergoing rapid revision! We would welcome your comments as this layer is being built.
The following design notes are a work-in-progress. The detailed design, implementation, testing and delivery of WCM services will be scoped according to WCM requirements and priorities. The initial refactor of WCM services will be phased. The following list is indicative, and is subject to change:
The WCM Services Layer will, at its core, be a new Alfresco Services API, implemented in Java and following the same standards / conventions as the existing Alfresco Service APIs. On top of this API will be layered new Javascript root scope object(s) (so that Javascript scripts, primarily Javascript based Web Scripts, are able to leverage this new API) as well as a set of Web Scripts that expose this API to remote callers (eg. Alfresco Web Studio).
Currently WCM assets are stored as a collection of different types of fundamental Alfresco asset types (DM spaces and nodes, AVM stores and nodes, aspects, etc.), which makes interacting with WCM assets time consuming and error prone. The WCM Services Layer will instead surface these objects via a unified POJO domain model, with Java interfaces representing each of the major types of WCM asset. Operations on that domain model (CRUD operations on Web Projects, sandbox-centric operations, etc.) will follow the same 'in-process SOA' architecture used elsewhere in the Alfresco APIs - ie. these operations will not be defined in the domain POJOs themselves, but will instead be defined in one or more stateless Services.
All of the new services defined as part of the WCM Services Layer will be implemented in a test friendly fashion - the code will be amenable not just to unit tests but also to benchmark / scalability tests. For the first release, as much as possible of the code will be validated by unit tests, while a WCM test suite will be added incrementally over time, as a secondary goal.
Except where it makes sense, the new APIs will not duplicate methods that already exist in the AVM APIs, but if this becomes necessary, the methods in the WCM Services Layer will simply delegate to the underlying APIs. Note that at this stage, the only place where duplication might make sense is for basic content operations (read file / write file) in the WebContentService.
The API set is defined in a WCM WebProject Service interface that, like other Alfresco Services, will be retrievable via the ServiceRegistry (getWebProjectService).
This service will provide CRUD operations on web projects, and also associated web apps and web users.
Exposed by REST Binding
JavaDoc (on HEAD) WebProjectService package
The WebProjectInfo domain object will include:
* nodeRef
* webProjectId
* name
* defaultWebApp
* title
* description
* isTemplate
JavaDoc (on HEAD) WebProjectService interface
Web Project operations:
Web Project webapp operations:
Web Project user operations:
The API set is defined in a WCM Sandbox Service Interface that, like other Alfresco Services, will be retrievable via the ServiceRegistry (getSandboxService).
This service provides CRUD operations on sandboxes, and ability to list compare sandboxes (ie. get modified items) and submit modified items to other sandboxes, or revert (undo) modified items.
Exposed by REST Binding
JavaDoc (on HEAD) Sandbox package
Sandboxes are associated with a single web project
There are various 'types' of sandbox including: staging sandbox, author sandbox, workflow sandbox, author workflow sandbox (and preview types of each)
The SandboxInfo domain object will include:
* sandboxId
* webProjectId
* sandboxType
* creator
* createdDate
* sandboxRootPath
JavaDoc (on HEAD) SandboxService interface
Web Project sandbox operations:
Sandboxes currently follow an internal naming convention (in terms of the underlying AVM store name) for example:
JavaDoc (on HEAD) AssetService interface
The API set is defined in a WCM Asset Service interface that, like other Alfresco Services, will be retrievable via the ServiceRegistry (getAssetService).
This service provides features for adding content to a WCM web project. It provides access to the AVM store in the context of a WCM web project and exposes methods which are friendly to web script/REST interfaces.
This service also provides bulk import to efficiently import large quantities of content.
The AssetInfo domain object will include:
* name
* sandboxId
* sandboxVersion
* path
* isFile
* isFolder
* isDeleted
* fileSize
* lockOwner
* creator
* createdDate
* modifier
* modifiedDate
Is this service required at all?
For non-Web-Form-backed content I'm not sure that there's much value in providing a higher level API over and above what the AVM already provides. That said, there is some value in having a single 'go to' API for all WCM content access and manipulation needs. Thoughts anyone?
Do we need an abstraction layer over the AVM store?
Does this service take onboard the XForms stuff ?
The API set will be defined in a WCM Deployment Service interface that, like other Alfresco Services, will be retrievable via the ServiceRegistry. This interface will provide:
Provides CRUD operations on configuring the deployment targets for a web project.
Provides access to deployment reports.
Provides a facade to the existing repo deployment service, to reduce the complexity and make the interface amenable to web scripts.
WCM deployment targets, will include the following properties (note: this list is indicative, not definitive):
* name
* display name
* hostname
* port number
* username
* password
* test server flag
* target (FSRs only)
* transport adapter
Interface inheritance will be used to differentiate ASRs and FSRs.
The following features are not essential, but are worthy of consideration.
TODO: is this necessary? Will Web Studio require the ability to manipulate Web Forms from day one?
The 'WebForm' domain object will include all of the properties defined for Web Forms, including the following (note: this list is indicative, not definitive):
The API set will be defined in a 'WebFormService' interface that, like other Alfresco Services, will be retrievable via the ServiceRegistry. This interface will provide:
Forms Definition operations (see also new Forms Service)
TODO: should this be extended to all WCM content, or just Web-Form-backed content?
The 'WebFormContent' domain object will include all of the properties defined for Web Form (XML) content, including the following (note: this list is indicative, not definitive):
* StoreRef (for accessing the content and aspects / properties etc.)
* name
* author
* creation date
* modification date
* parent Web Project
* originating Web Form (represented as a NodeRef to the DM space containing the Web Form)
The API set will be defined in a single 'WebFormContentService' interface that, like other Alfresco Services, will be retrievable via the ServiceRegistry. This interface will provide:
Note that this API will be fully sandbox aware ie. all operations will require a sandbox context to operate in. TODO: this poses issues for query / search, since that's currently only supported for staging sandboxes.
TODO: is this necessary? Will Web Studio require the ability to manipulate WCM workflows from day one?
The 'WCMWorkflow' domain object will include all of the properties defined for WCM Workflows, including the following (note: this list is indicative, not definitive):
The API set will be defined in a single 'WCMWorkflowService' interface that, like other Alfresco Services, will be retrievable via the ServiceRegistry. This interface will provide:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ask for and offer help to other Alfresco Content Services Users and members of the Alfresco team.
Related links:
By using this site, you are agreeing to allow us to collect and use cookies as outlined in Alfresco’s Cookie Statement and Terms of Use (and you have a legitimate interest in Alfresco and our products, authorizing us to contact you in such methods). If you are not ok with these terms, please do not use this website.