Skip navigation
All Places > Alfresco Content Services (ECM) > Blog > Authors bremmington
Alfresco 3.4.c Community release has just been released, and there are a few enhancements to Web Quick Start that are worth a mention.

Word-to-HTML conversion



A new rendering engine has been plugged in that takes .docx files and renders them into nice clean XHTML suitable for styling with CSS, and extracting images with appropriate embedded references to them. For example, if I specify a new rendition configuration named 'docxToHtml':

<bean class='org.alfresco.module.org_alfresco_module_wcmquickstart.rendition.BootstrapRenditionDefinition'>


<property name='name' value='docxToHtml' />


<property name='renderingEngineName' value='htmlRenderingEngine' />


<property name='parameters'>


<map>


<entry key='runAs' value='System' />


<entry key='destination-path-template' value='${cwd}/${name}.html' />


<entry key='bodyContentsOnly' value='true' />


<entry key='imagesSameFolder' value='true' />


</map>


</property>


</bean>


and then specify that that rendition should be triggered on the blog section of the WQS website whenever a docx file is uploaded by setting the 'Rendition Config' property on that section (note the ridiculously long MIME type):



If I then upload a Word document into the blog section of the website then it will be converted automatically into XHTML. As an example I uploaded the original Word version of one of Ben Hagan's blog posts, one page of which looks like this in Word:







Once uploaded into the blog section of the WQS site, browsing to the generated HTML rendition in Firefox looks like this:







No manual processing required - as soon as the upload of the original Word doc finished this HTML version was available to look at on the website. The markup's nice and clean too.

Asset-by-asset template override



Previously, it was possible to specify which page template to use on a type-by-type and section-by-section basis. That is to say that you define rules such as 'when rendering an article from the blog section use the 'articlepage2' template' or 'when rendering the landing page of the news section use the 'sectionpage3' template'. That remains the case in 3.4.c, but we have also added the ability to specify the template to be used for an individual asset. This is quite handy if you want most assets in a particular section to be rendered in a particular way but need one or two to look different.



We use it in the case of the homepage of the WQS website, as we want the default landing page template for sections to be 'sectionpage1', but for the landing page of the root section (the homepage of the website) we want to override this to use the template called 'homepage'. Therefore we set a template mapping on the root section for the normal case ('ws:indexPage=sectionpage1') and override the template on the index.html asset in the root section to be 'homepage':







Support for multiple WQS web apps in a single web container



In 3.4.b the logic that the WQS API used to determine which website was being addressed made use of the requested host name and port number but not the context of the addressed web application (the part of the URL that is 'wcmqs' in an out-of-the-box installation). This has been resolved in 3.4.c so that all three components are used to look up the correct website in the repository. The effect of this is to make it much simpler to deploy multiple websites that have differing functionality, since they can now all be deployed in a single instance of Tomcat, for example, without having to define multiple host names.



And some bug fixes, of course...



In addition to these things we have also fixed up some WQS bugs that we and members of the Alfresco community found in 3.4.b. As always, we're keen to hear your thoughts and ideas for future enhancements. If you have questions about or ideas for Web Quick Start then please visit the Web Quick Start forum and let us know. If you'd like to find out more about the Web Quick Start then take a look on the wiki.
The community version of Alfresco 3.4 (currently 3.4.b) has many shiny new features that have been much heralded. I thought that I would make my inaugural Alfresco blog post about a smaller, 'under-the-covers' addition that will hopefully be of use to some of you Alfresco developers out there: new policies for the transfer service.

The transfer service was introduced in version 3.3 to provide a means of pushing information out of an Alfresco repository to a receiver. We also built a repository receiver, thus enabling one Alfresco repository to push content to another Alfresco repository. You can read more about the 3.3 version of the transfer service on the Alfresco wiki. In 3.4, the transfer service has been extended to support many-to-one transfer and is used as the basis of the new replication service and also of the publishing mechanism used by Web Quick Start. For those unfamiliar with policies in Alfresco, they provide hook-points that allow you to plug your own java code ('behaviours') into the Alfresco system to make it do what you want it to do. If helpful, you can think of them as being a little like triggers in an RDBMS. There are many policies available in Alfresco, and they are an extremely powerful mechanism to customise Alfresco to your needs.

Something that was missing from the transfer service was the ability to hook into transfer-related events on the receiving end, so we have added three new policies that allow you to do just that. These are declared as sub-interfaces of the interface 'org.alfresco.service.cmr.transfer.TransferServicePolicies', and are named 'BeforeStartInboundTransferPolicy', 'OnStartInboundTransferPolicy', and 'OnEndInboundTransferPolicy'. All of these policies are invoked on the node type 'trx:transferRecord' (TransferModel.TYPE_TRANSFER_RECORD).

BeforeStartInboundTransferPolicy is invoked by the transfer receiver as soon as a request is received from a remote repository to start a transfer. At the moment a repository may only accept one inbound transfer at a time, and a lock is put in place to prevent more than one. This policy is fired before that lock is put in place, so if a behaviour that is hooked onto the policy throws an exception then the transfer request will be rejected without attempting to add the lock. Behaviours designed to hook onto this policy should specify an operation that follows the prototype defined by the BeforeStartInboundTransferPolicy interface:

  public void beforeStartInboundTransfer();


OnStartInboundTransferPolicy is invoked after the transfer lock has been put in place and an identifier has been allocated to the transfer, but before the identifier has been returned to the calling repository. The prototype of the operation that needs to be hooked onto this policy is:

  public void onStartInboundTransfer(String transferId);


OnEndInboundTransferPolicy is arguably the most useful of the three policies. It is fired at the end of an incoming transfer, and gives behaviours that are hooked onto it information about which nodes were created, updated, and deleted during the course of the transfer. The policy is triggered after the transfer has been committed, so allows custom post-processing of the affected nodes to be carried out. The prototype of the operation that is hooked onto this policy is:
  public void onEndInboundTransfer(String transferId, Set<NodeRef> createdNodes, Set<NodeRef> updatedNodes, Set<NodeRef> deletedNodes);



Together these three policies allow for a number of scenarios that were previously not possible. Hope you find them useful.

Filter Blog

By date: By tag: