Liferay in Action学习笔记

一、Liferay is a different portal

1、 Liferay is an application aggregator

To the left column, add Navigation, Activities Dictionary, and Translator.

To the right column, add Message Boards, Wiki, and Calendar

 

2. Liferay is a content manager system (CMS)

   Web content display

 

3. Liferay is a collaboration tool

Document Library

 

 WebDAV （Web-based Distributed Authoring and Versioning）

 

4. Liferay is anything you want it to be and any way you want it to look

 

 In about ten minutes—and without any additional
software—we've created a web site that contains web content, forums, a wiki, displays users' activities,
shares documents, and has a custom look and feel.

 

5.  A single Liferay Portal installation can host many different portals, all with separate users and content. 

 

 Roles are inherently linked to permissions. You’d use a role to collect users who have the same
permissions. A good example of this would be a Wiki Administrator role. This role would contain
users who have permission to administer wikis. 

 

 Organizations are hierarchical collections of users. Users can be members of one or many of
them, up and down the hierarchy. Membership in organizations gives users access to the pages
of that organization. If you picture a hierarchical structure that represents a company called
Inkwell, a user might belong to Inkwell, Sales Department, Mid-Atlantic Region. This would not
only denote that employee’s position in the company, but it would also give that employee access
to the content they need to do their job.

  

 Communities are ad hoc collections of users. Users can join and leave communities, and
membership in communities gives them access to the pages of the communities of which they’re
members. You might have a community called Photography. Users of your site could join this
community to share pictures.

 

 User Groups are defined by portal administrators. They can be used to collect users for purposes
that tend to cut across the portal. For example, you might want to grant some users the ability to
create a blog on your site. You would then create a User Group called Bloggers and create a page
template for them that contains Liferay’s Blog portlet. Regardless of these users’ membership in
other collections (as part of a hierarchy of organizations or as having joined several
communities), User Groups provide a separate way of granting specific access to functions that
don’t depend on membership in other collections or on specific portal permissions.

 

6. Adding content to a collection with pages

 

 Three types of collections can have not only users, but also pages. Pages are, of course, clickable,
navigable web pages. Organizations and Communities can have any number of pages defined within
them. Pages are organized into Layouts, and there are two types of Layouts: Public and Private. So each Organization or Community can have public pages, allowing them to configure a public web site which can be used by members and non-members of the Organization or Community. And they can also have private pages, which are only accessible by the members of the Organization or Community. So you can begin to see how you can build out your site and separate  functionality out by whoever is accessing the site. 

 

 User Groups don't have pages, but rather can have Page Templates. These are configured by
portal administrators, and become useful for users' personal communities. By default, each user gets a
personal community, which itself has public and private layouts. This is a personal web site which the
end user can configure (or which can be fairly static—or not exist at all, depending on how you have set
up the portal). Portal Administrators can create Page Templates for User Groups. These Page Templates
can be populated with the portlets that administrators want users to have. When users are then placed
into the User Group, any Page Templates are copied into those users' personal communities. So if, for
example, you want certain users to have a Blog, you might create a Blog page with the Blogs portlet on
it in a User Group called Bloggers. Any user you add to this user group would have this page copied
automatically to his or her personal community, and he or she can begin blogging immediately. 
        If you haven’t already figured it out, a Roles collection has no pages because roles are used solely to
define permissions. For example, you could define a role which has permission to view certain pages.
This is how roles work together with organizations, communities, and user groups. 

 

 7. Configuring a portlet’s scope

 Scope allows some of the concepts mentioned above to be refined. One user collection that is refined by
Scope is Roles. As stated above, Roles are the only collection to which permissions can be attached. So
you can create a Role called Wiki Administrator. This role would have permissions to the Wiki portlet,
allowing users in this role to create new wikis and add, edit, delete, and move pages. This role can be
created under one of two scopes: 
  Portal Role
  Community/Organization Role
If you created this role as a Portal Role, then any members of this role would have the defined
permissions across the whole portal, in any community or organization. So this would allow users in this
role to administer Wikis in whatever communities or organizations they have access to. You can,
however, define the role in another way, by scoping it only by community or organization. If the role
were defined this way,  then users would have the role's permission in only the community or
organization in which that role was defined. So scope is very important when it comes to how
permissions are defined. 

 

 二、 Getting Started with the Liferay Development Platform

2.1 Prerequisite: Installing the JDK

 

2.2 Installing a Liferay bundle

 

2.3 Setting up a database

mysqladmin -u root password NEWPASSWORD

mysql -u root -p

create database lportal character set utf8;

 

2.4 Removing the sample web site

The one you want to delete is called sevencogs-hook.

 

2.5 How to connect Liferay to the SQL database

 

portal-ext.properties

 

#
# MySQL
#
jdbc.default.driverClassName=com.mysql.jdbc.Driver
jdbc.default.url=jdbc:mysql://localhost/lportal?useUnicode=true&characterEncoding=UTF
-8&useFastDateParsing=false
jdbc.default.username=
jdbc.default.password=

 

You would provide the user name and password to the  database as values for the  username and
password directives. If you're using a different database, you'll find templates for the other databases in
Liferay's documentation. 
For a production machine, you would also generally connect Liferay to a mail server so that it can
send mail notifications. Since on a developer machine it is likely that there is no mail server running,
this step is not necessary. 
Save the file. You can now start your application server. 

 

2.6 Understanding portal development best practices

 

(1) Practices for developing applications

 

 To do development on the Liferay platform, you use the Plugins Software Development Kit (Plugins
SDK). This allows you to create your own portlets, themes, layouts, web modules, hooks, and
extensions with your own functionality and deploy them to Liferay. Liferay is primarily a consumer of
Java portlets, which can be implemented not only via the standard Portlet API, but also via several
frameworks such as Struts, Spring, or Java Server Faces. Liferay also supports “portlets” created using PHP, Ruby, or Python. The portlets you write can then be deployed to Liferay Portal and placed on portal pages, and this is how you implement your application.

 

     Themes are also created by using the Plugins SDK. You can very easily implement your own web
design in a theme project using your HTML, CSS, and JavaScript skills, and then deploy that design to
Liferay Portal. 

 

     You can customize some aspects of Liferay Portal by using a type of plugin called a Hook. Hooks
allow developers to extend Liferay's functionality by “hooking” into core features of the portal. You can modify core .jsps, insert custom events, alter portal properties, and add model object listeners. If this
makes no sense now, don't worry: we'll get to all of that. 

 

 (2)    Practices for customizing Liferay

    For these reasons, it is best to use the Ext plugin only if
you need to customize Liferay in a way that is not provided for already by hooks. 

 

 Using the Ext plugin, you can replace any of Liferay's .jsp files, Struts actions, Spring beans, or
utility classes with your own. Upon deployment, your modifications are overlaid with the Liferay source,
and the end result is a customized version of Liferay. You never touch any of Liferay's source to make
changes. This is how your upgrade path is kept clear. While there may be API changes between versions of Liferay (though effort is made to keep that to a minimum), it is a generally straightforward process to update your customized code to make the proper calls to an upgraded Liferay API. This allows you to take advantage of new features in the core functionality in your modified version of the Portal, because they are all kept separate. 

 

 (3)  When to use separate plugins, the Ext plugin, or both

 

    fulfill the requirements of your project. Remember that extending Liferay's functionality is rarely
required, and so it is likely that your project can be implemented using Liferay's core functionality with
your custom portlets and theme(s) added to it. If it's at all possible, you want to try doing everything
without the Ext plugin, as it definitely makes your life easier. Sometimes, this is not possible, and that's
why the Ext plugin is there. But you want to approach this exercise by seeing what you can do to
minimize your use of the Ext plugin. 

 

2.7 The Plugins SDK: a closer look
Plugins (portlets, themes, layout templates, hooks, and web modules) are how one adds functionality to
Liferay, and they have several benefits over using the Ext plugin: 
Plugins can be composed of multiple smaller portlet and theme projects. This reduces the complexity
of individual projects, allowing developers to more easily divide up project functionality. 
Plugins are completely separate from the Liferay core. Portlet plugins written to the Java standard
are deployable on any portlet container. 
Plugins can be hot deployed (i.e., deployed while the server is running) and are available
immediately. This prevents any server downtime for deployments. 
Enough theory. Let's get down to setting up and using  the Plugins SDK. You'll see how to use the
Plugins SDK with just a text editor and Ant as well as with two of the leading open source IDEs.

 

(1) INSTALLING THE PLUGINS SDK

 

(2) Configuring the Plugins SDKs

 

 You will notice that the Plugins SDK contains a file called build.properties. Open this file in a text editor. At the top of the file is a message, “DO NOT EDIT THIS FILE.” I just wanted you to see that (pictured in figure 2.3). This file contains the settings for where you have Liferay installed and where your deployment folder is going to be, but you don't want to customize this file. Instead, create a new file in the same folder called build.[username].properties, where [username] is your user ID on your machine. This is the ID you log in with every day. For example, if your user name is cooldude, you would create a file called build.cooldude.properties. 
If you're using the default setup I've described so far, you won't have to do very much to set up the
Plugins SDK. Create your build.[username].properties file and put in the following line:
app.server.dir=[full path to Liferay bundle install]

 

 If you use Eclipse as your development environment, you may also find it convenient to modify the
following property: 
java.compiler=
java.compiler: The default value for this is the standard compiler that comes with Java, modern. You
can also use the Eclipse compiler, ECJ. ECJ is an alternate Java compiler with fast performance that
allows you also to replace code in memory at run time (called hot code replace). If you set this option to
use ECJ, the ant script will install it for you by copying ecj.jar to your Ant folder. This may or may not
work with the version of Ant that runs from within various integrated development environments. 
Save the file. 
You should now have a directory structure that looks like this: 
[Code Home]/bundles/[Liferay Bundle]
[Code Home]/plugins
You are now ready to start using the plugins SDK. 

 

2.8 Using the Plugins SDK

 

 (1) Creating plugins

 

 create.bat hello-world "Hello World"

 

 (2) Deploying plugins

 

 ant deploy

 

 -Dfile.encoding=UTF8 -Duser.timezone=GMT -Xmx1024m -XX:MaxPermSize=256m -Dexternal-
properties=portal-developer.properties

 

 Next, select  Add External Jars  and then browse to your Liferay-Tomcat bundle folder. Browse to
webapps/ROOT/WEB-INF/lib and then select the following .jars: 
commons-logging.jar
util-java.jar
util-taglib.jar
util-bridges.jar

 

[Liferay Install Location]/lib/servlet-api.jar
[Liferay Install Location]/lib/jsp-api.jar
[Liferay Install Location]/lib/ext/portal-kernel.jar
[Liferay Install Location]/lib/ext/portal-service.jar
[Liferay Install Location]/lib/ext/portlet.jar
[Liferay Install Location]/lib/ext/activation.jar
[Liferay Install Location]/lib/ext/annotations.jar
[Liferay Install Location]/lib/ext/hsql.jar
[Liferay Install Location]/lib/ext/jms.jar
[Liferay Install Location]/lib/ext/jta.jar
[Liferay Install Location]/lib/ext/mail.jar
[Liferay Install Location]/lib/ext/mysql.jar
[Liferay Install Location]/lib/ext/postgresql.jar
[Liferay Install Location]/webapps/ROOT/WEB-INF/lib/util-taglib.jar
[Liferay Install Location]/webapps/ROOT/WEB-INF/lib/util-bridges.jar
[Liferay Install Location]/webapps/ROOT/WEB-INF/lib/util-java.jar
[Liferay Install Location]/webapps/ROOT/WEB-INF/lib/jstl-impl.jar
[Liferay Install Location]/webapps/ROOT/WEB-INF/lib/jstl.jar
[Liferay Install Location]/webapps/ROOT/WEB-INF/lib/commons-logging.jar

 

 三、 Portlets are easy

 

As a developer, you are free to concentrate only on your application and its functionality, and you
don't have to worry about all the ancillary things like users, user management, registration, layout,
permissions, and the like. That stuff is built into the portal, and you get to simply take advantage of it in your application. 

 

 portlet.xml   with web.xml

 

 Render Phase: runs whenever the portlet needs to re-draw itself on the page
Action Phase: called as the result of an ActionURL. This allows the portlet to do some processing
to change its state, which is then reflected when the portlet is rendered again. 
Event Phase: called as the result of an event being fired. Events can be fired in the Action phase of
the portlet and are processed during the Event phase. 
Resource Serving Phase: called by the serveResource method. This is used for directly serving
a particular resource without calling any other part of the lifecycle, and was particularly designed with
AJAX in mind. 

 

 Portlets have additional characteristics that make them different from servlets. Portlets have several
different Portlet Modes. Portlet Modes indicate the function the portlet is performing. The three standard
modes are View, Edit, and Help. View mode is the standard mode of the portlet when it is first
displayed. This can consist of one or more screens of functionality within the portlet window. Edit mode is a mode where portlet configuration can be done. For example, a weather portlet can be placed into
edit mode, where a user can enter a zip code that causes the portlet to show the forecast for that
location when it is in View mode. Help mode is a separate mode that can be used to display help text
about the portlet.

 

Portlets also have  Window States  in which they can be displayed. Portlets can be maximized,
minimized, or in regular mode. A maximized portlet takes up the whole portlet area. A minimized portlet shows only its title bar. And a portlet in regular mode can be on a page with several other portlets at the same time. 

 

Sample "Hello You"

 

(1)  liferay-display.xml 

This file describes for Liferay what category the portlet should appear under in the Add > More window. 

 

(2) liferay-portlet.xml 

This file describes some optional Liferay-specific
enhancements for Java portlets that are installed on a
Liferay Portal server. For example, you can set whether a
portlet is instanceable, which means that you can place
more than one instance on a page, and each portlet will
have its own data. The DTD for this file explains all of the
possible settings. 

 

(3) liferay-plugin-package.properties 

This file describes the plugin to Liferay's hot deployer.
One of the things that can be configured in this file is
dependency .jars. If a portlet plugin has dependencies on
particular .jar files that already come with Liferay, you can
specify them in this file and the hot deployer will modify
the .war file on deployment so that those .jars get copied
from Liferay into the WEB-INF/lib folder of the .war file.
This prevents you from having to include .jar files (such
as Spring, Struts, or Hibernate) in your portlet project that
are already used by Liferay.

 

<portlet-class>com.liferay.util.bridges.mvc.MVCPortlet</portlet-class>

<portlet-class>com.liferayinaction.portlet.HelloYouPortlet</portlet-class>

 

<supports>
  <mime-type>text/html</mime-type>
  <portlet-mode>view</portlet-mode>
     <portlet-mode>edit</portlet-mode>
</supports>

 

   <init-param>
   <name>edit-jsp</name>
   <value>/edit.jsp</value>
  </init-param>

 

Create a package in your  src  folder called  com.liferayinaction.portlet. In this package,
create a Java class called HelloYouPortlet.java. This class will extend the GenericPortlet class,
which is included with the Portlet API and is available in every portal implementation. So far, your class
should look like the following code.

 

extends GenericPortlet

 

public void init()

doView()

doEdit()