Sean Champ's List: Liferay

• If an application lives outside the portal, the portal should be able to consume some resource of the application (such as an RSS feed or a subset of functionality in a "dashboard" application) so that the end user can see everything he or she interacts with at a glance.
• integrated together in a consistent and systematic way
• all the application functionality within Liferay Portal resides in fragments of the page called portlets.
• Liferay's core is a portlet container that aggregates portlets on particular pages and displays them to users
• Portlets are web applications that run in a portion of a web page.
• one or many applications can reside on a page
• users can (at the administrator's discretion) arrange them however they like.
• Portlet applications, like servlet applications, are defined by a Java standard which various portal server vendors have implemented. The Java standard defines the portlet specification. A JSR-168 or JSR-286 standard portlet should
• 1) multiple portlets which only provide small amounts of functionality individually, but are aggregated by the portal server
• 2) whole applications which reside in only one application window
• Liferay provides a Plugins Software Development Kit
• Liferay in Action, published by Manning Publications, which is the official guide to Liferay development.
• Liferay supports portlets written in other programming languages, such as PHP, Ruby, Groovy, or Python
• Sample portlets written in these languages
• Liferay's public plugin repository on Github at https://github.com/liferay/liferay-plugins.

13 more annotations...

• Portal Architecture
• Users can belong to organizations
• Users can be collected into user groups
• Organizations can be grouped into hierarchies, such as Home Office → Regional Office → Satellite Office.
• users can belong to teams
• Within sites
• Sites can be created independently or can be attached to users or organizations.
• for specific functions within a site.
• Figure 1.8: Liferay's User Collection Model
• permissions within a particular organization or site.
• Liferay manages permissions for users and collections of users via roles.
• can also be scoped to customize permissions that cut across the entire portal.
• or example, a Message Boards Administrator role could be created that grants permissions to administer any message board in the portal.
• Alternatively, a similar role could be created that grants those permissions only for a particular organization or site.
• Roles provide a powerful mechanism for administrators to configure portal resources and security in a consistent and robust manner.
• Teams belong to individual sites.
• although each site in the portal may have access to a particular role with its configured permissions, membership in this role can be different for each site and the granted permissions only apply within one site
• By default, users get their own private sites with public and private pages that they can manage themselves.
• they enable users to have their own public blog or their own private calendar, a place to store their documents, and more.
• If, however, you don't want users to have personal sites, this default behavior can be turned off by a portal administrator
• the portal-ext.properties configuration file (see chapter 14).
• Liferay uses site templates to control the default portlets that appear on the public and private pages of user's personal sites
• See chapter 3 for information about templates.
• Roles

  • Notice that this doesn't specify where or how roles can be created - presumably, that would be addressed in another section of the user guide, or perhaps in the developer guide.

• There are three kinds of roles:

  • Portal Roles

  • Organization Roles

  • Site Roles
• role scopes
• Roles are used to define permissions across their scopes: across the portal, across an organization, or across a site.
• Note: It is important to understand Liferay's portal architecture concepts before assigning roles. For example, assigning roles to an open site could create a security problem within your porta
• Roles can be assigned to users, user groups, organizations, and sites
• Organizations are hierarchical collections of Users.
• Organizations can't have pages directly associated with them.
• There is also a special type of organization called a location, which can't have any suborganizations
• sites can be attached to organizations.
• Organizations need sites in order to have pages.
• If certain users have been granted the manage pages permission, they will be able to create and maintain pages within an organization.
• Sites are simply collections of pages
• Sites can contain public pages, which are accessible to all portal users, and private pages, which are only accessible to site members.
• Liferay's default pages are part of a site named for the portal because all portal users have a common interest in the default, public pages of your site

• here are three types of sites:

  • Open

  • Restricted

  • Private
• An open site (the default) allows portal users to join and leave the site whenever they want to
• A restricted site requires that users be added to the site by a site administrator.
• My Sites portlet
• Users can request membership in a restricted site using the control panel or the My Sites portlet.
• A private site is just like a restricted site except that it is invisible to non-members in the control panel and in the My Sites portlet.
• Teams are sets of users with similar permissions within a site.
• teams appear only in the site in which they are created.
• Site administrators can't create roles,
• Generally speaking, Site Administrators cannot view or access the content of the portal as a whole, but only have access to the content and resources of their own Site.
• if they are managing users in the Users and Organizations interface, they can view all of the users and organizations on the entire portal.
• They need this capability to effectively add and manage the users of their own site
• if privacy is a concern on your portal, you will need to be concious of which users are granted the Site Administrator role.

49 more annotations...

• Managing Pages in Liferay Portal

• Liferay's Kaleo workflow engine ships with CE versions of Liferay
• the plugin can be installed through the Liferay marketplace
• The name is kaleo-web
• new options to the control panel:
• My Workflow Tasks
• Workflow Configuration
• My Submissions
• • Workflow
• requires one approval before an asset can be published.
• There is one workflow that comes bundled with the kaleo-web plugin: Single Approver Workflow
• roles that are specified in the workflow definition are created automatically when the definition is deployed.
• The Single Approver Workflow contains three roles each with different scopes
• Site Content Reviewer
• Portal Content Reviewer.
• Organization Content Reviewer

13 more annotations...

• • For more information on Aperte workflow, see http://www.liferay.com/community/forums/-/message_boards/message/12587623

  • Alternate option (?) Aperte Workflow - http://www.aperteworkflow.org/web/guest
    
    Note that Kaleo is not a full BPM implementation.
    
    For opinion on Aperte's differences with regards to Kaleo, see http://www.aperteworkflow.org/forum/-/message_boards/view_message/14353
• A Kaleo workflow, called a process definition, is defined in an XML file
• workflow-definition xmlns="urn:liferay.com:liferay-workflow_6.1.0"

  • Note that this is not the same syntax as with jBPM

1 more annotation...

• To point your Liferay bundle to your database

• Liferay comes bundled with its own built-in data source.
• , a JNDI lookup provides a handle to the data source, and the application server manages the connection pools. Liferay supports using your application server's data source if you wish to do that.
• you'll need to create your own configuration file and skip the setup wizard.
• Liferay's default configuration looks for a mail server on the same machine on which Liferay's running, and it tries to send mail via SMTP to this serve
• two ways to configure your mail server:
• The default configuration file is called portal.properties, and it resides inside of the portal-impl.jar file.
• Next, you need several .jar files which are included as part of the Liferay source distribution. Many application servers ship with these already on the class path, but Tomcat does not.
• download the Liferay source code and get them from there.
• rom $LIFERAY_SOURCE/lib/development to your $TOMCAT_HOME/lib/ext
• from $LIFERAY_SOURCE/lib/portal to your $TOMCAT_HOME/lib/ext
• rom $LIFERAY_SOURCE/lib/development to your $TOMCAT_HOME/temp/liferay/com/liferay/portal/deploy/dependencies
• Domain Configuration
• setenv.bat (Windows) or setenv.sh
• sets the character encoding to UTF-8, sets the time zone to Greenwich Mean Time, and allocates memory to the Java virtual machine.
• directory $TOMCAT_HOME/conf/Catalina/localhost and create a ROOT.xml file in it
• populate it with the following contents to set up a portal web application:
• Setting crossContext="true" allows multiple web apps to use the same class loader

  • setting crossContext to 'true' may result not only in the sharing of the class loader, but may also  allow capture of data across web applications, using ServletContext.getContext() - see the URL denoted in the previous comment.

  • Note: "The use of crossContext is both rare and potentially insecure." - http://stackoverflow.com/questions/661978/what-does-the-crosscontext-attribute-do-in-tomcat-does-it-enable-session-sharin
• $TOMCAT_HOME/conf/catalina.properties
• replace the line:
• common.loader
• ${catalina.home}/lib/ext,${catalina.home}/lib/ext/*.jar
• allows Catalina to access the dependency jars that you extracted to $TOMCAT_HOME/lib/ext.
• add the attribute URIEncoding="UTF-8" to your connector
• $TOMCAT_HOME/conf/server.xml
• Connector
• URIEncoding="UTF-8"
• Make sure that there is no support-catalina.jar file in your $TOMCAT_HOME/webapps directory
• Database Configuration
• . If you want to use Liferay's built-in data source, you can skip this section.

  • How does this pertain to external database storage? Can Liferay manage an external database without this step?
• Resource

  • Be sure to document this decision, in the administrative guide for the portal
• name="jdbc/LiferayPool"
• If you want to manage your mail session within Tomcat, use the following instructions
• Edit $TOMCAT_ HOME/conf/Catalina/localhost/ROOT.xml and configure a mail session.
• Resource

  • Be sure to document this resource, in the administration guide for the portal.
• name="mail/MailSession"
• f you are using Tomcat to manage your data source, add the following to your portal-ext.properties file in your Liferay Home to refer to your data source:
• jdbc.default.jndi.name
• if you are using Liferay Portal to manage your data source, follow the instructions in the Deploy Liferay section for using the setup wizard.
• use Liferay Portal to manage your mail session
• , if you are using Tomcat to manage your mail session, add the following to your portal-ext.properties file
• mail.session.jndi.name
• delete the contents of the $TOMCAT_HOME/webapps/ROOT directory

  • Also delete the file ROOT.war in that directory, if present.
• Then extract the Liferay .war file to $TOMCAT_HOME/webapps/ROOT.

  • One could alternately copy the liferay WAR file as ROOT.war in that directory - that resulting in the deployment of the WAR as the ROOT web application, after Tomcat's next successful start
• setup.wizard.enabled=false
• portal-setup-wizard.properties file the setup wizard creates should have setup.wizard.enabled=false conveniently specified for you.

43 more annotations...

• Stop Tomcat
• Move ROOT.war aside and rm -rf webapps/ROOT
• Copy the webapp you want to webapps/ROOT.war
• Start Tomcat

2 more annotations...

• the use of crossContext is both rare and potentially insecure

• give each web application its own ServletContextListener which loads the desired bundle and stores it as an attribute of the ServletContext during the contextInitialized() method.

• However, in some circumstances, it is desirable that two or more  network names should resolve to the same virtual host,  running the same set of applications.
• This is accomplished by utilizing one or more Alias  elements nested inside your Host element.

• Add the jamwiki portlet to the page; it will be located in the "Undefined" category
• Follow the normal jamwiki installation process
• Refreshing your browser without clicking on "Permanent Link" will return you to the application's home page.
• Login credentials cannot be shared with the embedded application.
• the Iframe portlet.

3 more annotations...

• Folksonomies are represented by tags
• The tagging system provided by default by Liferay supports both taxonomies and folksonomies
• tags are freeform
• Taxonomies are represented by categories
• ategories are declared before and the user can only select from a set
• Categories can be classified in vocabularies
• can be hierarchical.
• Any content can be tagged or categorized as soon as it has an asset associated.
• In order to use Liferay tags and categories, you just need to create an Asset for each of your contents
• Taglibs (can be used in your own portlets)
• Portlets

9 more annotations...

• Vaadin application is a Java file extending com.vaadin.Application class
• created for every user accessing the application
• the init() function is invoked to initialize user interface.

  • Sublimely simple!
• Using Vaadin Add-ons

2 more annotations...

• com.liferay.maven.archetypes:liferay-ext-archetype
• com.liferay.maven.archetypes:liferay-hook-archetype
• com.liferay.maven.archetypes:liferay-layouttpl-archetype
• com.liferay.maven.archetypes:liferay-portlet-archetype
• com.liferay.maven.archetypes:liferay-servicebuilder-archetype
• com.liferay.maven.archetypes:liferay-theme-archetype
• com.liferay.maven.archetypes:liferay-web-archetype
• css

  sample-portlet/src/main/webapp/css/main.css
• icon.png
• js

  sample-portlet/src/main/webapp/js/main.js
• view.jsp
• sample-portlet/src/main/webapp/WEB-INF/liferay-display.xml

  sample-portlet/src/main/webapp/WEB-INF/liferay-plugin-package.properties

  sample-portlet/src/main/webapp/WEB-INF/liferay-portlet.xml

  sample-portlet/src/main/webapp/WEB-INF/portlet.xml

  sample-portlet/src/main/webapp/WEB-INF/web.xml

10 more annotations...

• the main functionalities that you will be able to reuse thanks to the asset framework:
• tags to custom content types
• categories to custom content types
• Manage tags from the control panel
• Manage categories from the control panel
• comments
• Rate of assets
• social bookmarks (e.g. via tweet, Facebook like, or +1 (Google Plus))
• custom fields
• Relate assets to one another
• Flag asset content
• the number of visualizations of an asset
• Integrate workflow with assets
• using the Asset Publisher portlet.
• Whenever one of your custom content is created you need to let the asset framework know.
• All the methods that you will need to invoke are part of the AssetEntryLocalService.
• using either the static methods of AssetLocalServiceUtil or by using an instance of the AssetEntryLocalService injected by Spring.
• we will be using the former, since it doesn’t require any special setup in your application.
• The method that you need to invoke when one of your custom content has been added or updated is the same and is called updateEntry.
• AssetEntry updateEntry
• long classPK

  • aka "primary key", also used with an asset's AssetRenderFactory and AssetRenderer implementations
• long groupId

  • for one thing, it looks like the groupId value would be used with "url Title" (?) in getAssetRenderer(...)
• When one of your custom content is deleted you should also let the Asset Framework know
• void deleteEntry

• an example invocation extracted again from the blogs portlet:

  assetEntryLocalService.deleteEntry(     BlogsEntry.class.getName(), entry.getEntryId());
• how does a content author specify such tags and categories?
• Liferay provides a set of JSP tags that you can use to make this task very easy.
• liferay-ui:asset-tags-selector
• liferay-ui:asset-categories-selector
• liferay-ui:asset-tags-summary
• liferay-ui:asset-categories-summary
• More JSP tags for assets
• Publishing assets with Asset Publisher
• In order to be able to display your assets, the Asset Publisher needs to know how to access the metadata of your assets.
• Additionally, you need to provide the Asset Publisher with templates for the types of views (e.g. full view and abstract view)
• by implementing the following pair of interfaces
• AssetRendererFactory
• can be anything you have specified to the updateAsset method
• The classPK is typically the asset’s primary key,
• Your factory implementation should be able to grab the asset from a groupId (identifies a scope of data) and a urlTitle (a title that can be used in friendly URLs to refer uniquely to the asset within a given scope)

  • nullWhat does this mean by "Grab" ? (Perhaps the example code, in the following, will serve to clarify the meaning of this statement) -- 2012-07-28
    Presumably, this refers to the asset's implementation of the AssetRenderFactory#getAssetRenderer() method -- 2012-07-28
    
• the asset renderer factory can provide a URL for the Asset Publisher to use when a user wants to add a new asset of your custom type
• should point to your own portlet.

  • How does a URL "point to" a portlet?
• other less important methods of the interface, but you can avoid implementing them by extending BaseAssetRendererFactory
• AssetRenderer
• an example of these two classes.
• BlogsEntryAssetRendererFactory
• extends BaseAssetRendererFactory
• BlogsEntry.class.getName()

  • for getClassName()
• TYPE = "blog"

  • for #getType()
• AssetRenderer getAssetRenderer

  • nullThis isn't annotated with @Override... -- 2012-07-28
    This method is inherited from AssetRendererFactory (interface) by BaseAssetRendererFactory (an abstract class). Presumably, it would be up to the implementing class to define this method. So, what do these arguments mean? and how does this "fit" with other methods of the same name but different method signatures? -- 2012-07-28
    
• long classPK, int type

  • Note that the 'type' parameter is unused, in this method (why?)
• BlogsEntryLocalServiceUtil.getEntry(classPK)

  • nullThere's a logic in this call that this article does not even begin to describe. -- 2012-07-28
    See also:
    http://docs.liferay.com/portal/6.1/javadocs/com/liferay/portlet/blogs/service/BlogsEntryLocalServiceUtil.html -- 2012-07-28
    
• @Override  public AssetRenderer getAssetRenderer
• long groupId, String urlTitle

  • What does 'urlTitle' mean? Presumably, it would be a URL fragment, so ... ???
• getEntry(groupId, urlTitle)
• new BlogsEntryAssetRenderer(entry)
• @Override  public PortletURL getURLAdd
• LiferayPortletRequest liferayPortletRequest,  LiferayPortletResponse liferayPortletResponse
• HttpServletRequest request
• if (!BlogsPermission.contains(  themeDisplay.getPermissionChecker(),  themeDisplay.getScopeGroupId(), ActionKeys.ADD_ENTRY)) {   return null;  }

  • nullWhat is the logic of this design? The article doesn't usefully describe it -- 2012-07-28
    This is evidently a part of the blog portlet's security implementation - the permissions are checked not until the user attempts to add a blog entry? -- 2012-07-28
    Well, at any rate, the permissions are checked here, at least - *should* also be checked in the UI, when the user begins to edit a new blog entry. -- 2012-07-28
    
• PortletURL portletURL = PortletURLFactoryUtil.create

  • see also http://docs.liferay.com/portal/6.1/javadocs/com/liferay/portlet/PortletURLFactoryUtil.html
• getControlPanelPlid(themeDisplay)

  • ???
• portletURL.setParameter("struts_action", "/blogs/edit_entry");
• @Override  public boolean hasPermission
• @Override  public boolean isLinkable()
• @Override  protected String getIconPath
• BlogsEntryAssetRenderer
• extends BaseAssetRenderer
• BlogsEntryAssetRenderer(BlogsEntry entry)

  • A constructor with one argument - presumably due to design decisions (not discussed here) of the asset framework/API
• _entry.getEntryId()
• @Override  public String getDiscussionPath()
• return "edit_entry_discussion"

  • Presumably, this means something as a feature of the design of the Liferay Blog portlet
• @Override  public PortletURL getURLEdit
• @Override  public String getUrlTitle()
• @Override  public PortletURL getURLView
• @Override  public String getURLViewInContext
• @Override  public boolean hasEditPermission
• @Override  public boolean hasViewPermission
• @Override  public boolean isPrintable()
• @Override  protected String getIconPath

78 more annotations...