Thursday, December 4, 2014

Application Display Template - Documents and Media - Reading the Field Value from Document Type

For last couple of days I have been working on this new feature introduced in Liferay 6.2 Application Display Templates (aka ADT).

ADT Provides adding custom display settings to our portlets. Initially when liferay 6.2 was released ADT can only be applied to a specified list of  OOTB portlets

  • Asset Publisher
  • Blogs
  • Categories Navigation
  • Media Gallery
  • Site Map
  • Tags Navigation
  • Wiki
But later the scope is extended to have ADT's for custom portlets as well. 

That being said let me focus of the heading of this blog.

Document Type holds the meta data of the document and can be created in the liferay portal with different scopes (Global, Portal, Site). Document Type can be defined to have different fields with different data types.  We can also restrict a folder to have a specified document type. 

There is no direct API for retrieving the document type field values for a given document, for a given document.  Thus it becomes more complicated to retrieve those in the free marker template.

  1. By default serviceLocator variable is restricted in portal.properties we need to enable serviceLocator in portal-ext.properties, by adding below line,  so that we can access different liferay servcies. 
    • freemarker.engine.restricted.variables=
  2. Retrieve DLFileEntryLocalService with service Locator
    • <#assign dlFileEntryService = serviceLocator.findService("com.liferay.portlet.documentlibrary.service.DLFileEntryLocalService")>
  3. Retrieve the DLFileEntry Object for a given FileEntry Object
    • <#assign dlFileEntry = dlFileEntryService.getFileEntry(curFileEntry.getFileEntryId() )>
  4. From the DLFileEntry get all the fields available as Map.
    • <#assign fieldsMap = dlFileEntry.getFieldsMap(dlFileEntry.getFileVersion().getFileVersionId()) >
  5. Now Iterate through the Map and retrieve the fields available in the document type of a given document.
    <#list fieldsMap?keys as structureKey>

    <#list fieldsMap[structureKey].iterator() as field>
    <#assign imgList = imgList + {field.getValue():curFileEntry}> 
    </#list>
    </#list>

That is all we need to do. 


Here are some useful links that might be helpful while developing the ADT's 

http://www.liferay.com/web/james.falkner/blog/-/blogs/dumping-adt-wcm-template-variables?_33_redirect=http%3A%2F%2Fwww.liferay.com%2Fweb%2Fjames.falkner%2Fblog%3Fp_p_id%3D33%26p_p_lifecycle%3D0%26p_p_state%3Dnormal%26p_p_mode%3Dview%26p_p_col_id%3Dcolumn-2%26p_p_col_count%3D1
https://www.liferay.com/community/forums/-/message_boards/message/44019133
https://www.liferay.com/es/community/forums/-/message_boards/message/44197544
https://issues.liferay.com/browse/LPS-50931
http://www.liferay.com/web/eduardo.garcia/blog/-/blogs/new-ways-of-customization-with-application-display-templates-part-i-
http://www.liferay.com/web/eduardo.garcia/blog/-/blogs/new-ways-of-customization-with-application-display-templates-part-ii-
 

Kaleo Workflow Limitations and Considerations.

Limitations w.r.t liferay 6.1.20

  • Can not have multiple terminal (end) states.
  • Can not send notifications in the terminal state for the roles though it can send the notifications to users specified.
  • There is no scripted assignment for notifications separately. In other words, <recipients> tag in the <notifications> does not have a provision for scripted assignment. 


Things to be considered while developing the Kaleo workflows.


  • When ever there is a script error, workflow engine does not give/throw the exception and swallows the exception silently.
  • The only way to check whether the script executes perfectly or not is not copy the script and run that script in the Control Panel --> Server Administration --> Scripts console and debug there.
  • Scripted assignment is present at <Task> level. If the notification does not have < recipients> tag, then the notification uses the assignment tag specified at the task level. Thus, task assignment and notifications are sent to the same set of users.





Monday, August 4, 2014

Override annotation compilation problem - Liferay 6.1 Plugins SDK

You have classes implementing interface methods, which in Java 1.6 can be annotated with @Override; however, in Java 1.5, @override could only be applied to methods overriding a superclass method.

So while using liferay 6.1 plugins SDK, if you use @override annotations for implementing interface methods, though the server JDK is at 1.6, it still complains, resulting in not compiling the class with that annotation. Here is the example:

When creating a model listener hook, you need to implement all of the methods present in the ModelListener interface. If the implemented class has annotation "override", while building using the ant, it gives compilation error. 

Temporary fix

Remove @override annotation and build the project using ant.

Permanent Fix

To solve this issue the compiler compliance level should be set to 1.6. As we are building from ant, we have to set the compiler compliance level of ant. This can be set in build.properties file present in the plugins SDK root directory. All you need to do is change the following properties to 1.6

ant.build.javac.source=1.6

ant.build.javac.target=1.6