Hooks and plugin Ext in Liferay portal 6

In summary, the portal (6.0 or above) supports six different types of plugins out-of-the-box. They are portlets, themes, layout templates, webs, hooks, and ext.

• Portlets: web applications that run in a portion of a web page;
• Themes: look and feel of pages;
• Layout Templates: ways of choosing how the portlets will be arranged on a page;
• Hooks: allow hooking into the portal core functionality;
• Webs: regular Java EE web modules designed to work with the portal, like ESB (Enterprise Service Bus), SSO (Single Sign-On), etc.
• Ext: ext environment as a plugin.

Abstracted from the book: Liferay Portal 6 Enterprise Intranets
This article will share two cool features - Hooks and Plugins Ext - in Liferay portal 6. Speciall thanks to Amos Fong, so that we could minimize the ext environment by using hooks. A lot of thanks to Brian Chan, who coined terms "Hook" and "Plugin Ext" and implemented them as part of wonderful features in Liferay portal 6.
Plugin Ext
Ext environment is now available as a plugin.
You would know how to use it (plugin Ext) by an example - hello-world-ext.
Under hello-world-ext/docroot/WEB-INF, you'll see a lot of folders that start with ext-* as shown in following screenshot.

• ext-impl/src contains code that will override portal-impl/src
• ext-lib/global is where you put jars that are available in the global class loader
• ext-lib/portal is where you put jars that are available only to the portal class loader
• ext-service/src contains code that will override portal-kernel/src and portal-service/src
• ext-util-bridges/src contains code that will override util-bridges/src
• ext-util-java/src contains code that will override util-java/src
• ext-util-taglib/src contains code that will override util-taglib/src
• ext-web/docroot contains code that will override portal-web.

Note that if you modify ext-web/docroot/WEB-INF/web.xml, those changes are merged into portal-web/WEB-INF/web.xml. ext-web also contains /WEB-INF/*-ext.xml files that are used to override what is in portal-web.
and more ... You could refer to LPS-6341 and Ext environment and the Ext Plugin in 6.x.
As you can see, It works very similarly to that of Ext environment, but it is now much smaller and lighter weight.

Note that support for ServiceBuilder in EXT plugins will be deprecated in future versions. EXT plugins are designed to override the portal's core code that cannot be done with hooks, layout templates, portlets, or themes. EXT plugins are not meant to contain new custom services. Thus migrate your service.xml of 5.x to a portlet plugin.

Open Issues
Of course, it would be nice that the plugin Ext should have same functions and features as that of Ext environment. Actually there are still a set of open issues that should get fixed in future release.The following are some of them.

• Web Services (fixed): LPS-7279
• Dynamic SQL (fixed): LPS-6738

Hooks

Hooks is a feature to catch hold of the properties and JSP files into an instance of the portal as if catching them with a hook. Hook plugins are more powerful plugins that come to complement portlets, themes, layout templates, and web modules. A hook plugin is always combined with a portlet plugin. For instance, the portlet so-portlet is a portlet plugin for Social Office with hooks. In general, hooks would be very helpful tools to customize the portal without touching the code part of the portal. In addition, you would use hooks to provide patches for the portal systems or social office products. 
Abstracted from the book: Liferay Portal 6 Enterprise Intranets (coming out soon)
Setup
In general, there are four kinds of hook parameters: portal-properties (called portal properties hooks), language-properties (called language properties hooks), custom-jsp-dir (called custom JSPs hooks) and service (called portal service hooks) as specified in $PORTAL_ROOT_HOME/dtd/liferay-hook_6_0_0.dtd.
<!ELEMENT hook (portal-properties?, language-properties*, custom-jsp-dir?, service*)>
<!ELEMENT portal-properties (#PCDATA)>
<!ELEMENT language-properties (#PCDATA)>
<!ELEMENT custom-jsp-dir (#PCDATA)>
<!ELEMENT service (service-type, service-impl)>
<!ELEMENT service-type (#PCDATA)>
<!ELEMENT service-impl (#PCDATA)>
As shown in the preceding code, the ordering of elements is significant in the DTD (Document Type Definition) - you need to have your portal properties (only one marked by ?), language properties (could be many marked by *), custom-jsp-dir (only one marked by ?) and service (could be many marked by *) declared in the same order.
Language properties hooks allow us to install new translations or override few words in existing translations. JSP hooks provide a way to easily modify JSP files without having to alter the core of the portal, whereas portal properties hooks allow runtime re-configuration of the portal. Portal service hooks provide a way to easily override portal services. The portal configuration properties can be altered by specifying an override file, where the properties will immediately take effect when deployed.
Note that not all portal properties can be overridden via a hook. The supported properties are:

auth.forward.by.last.path
auto.deploy.listeners
application.startup.events
auth.failure
auth.max.failures
auth.pipeline.post
auth.pipeline.pre
auto.login.hooks
captcha.check.portal.create_account
control.panel.entry.class.default
default.landing.page.path
dl.hook.impl
field.enable.com.liferay.portal.model.Contact.birthday
field.enable.com.liferay.portal.model.Contact.male
field.enable.com.liferay.portal.model.Organization.status
hot.deploy.listeners
image.hook.impl
javascript.fast.load
layout.static.portlets.all
layout.template.cache.enabled
layout.user.private.layouts.auto.create
layout.user.private.layouts.enabled
layout.user.private.layouts.modifiable
layout.user.public.layouts.auto.create
layout.user.public.layouts.enabled
layout.user.public.layouts.modifiable
ldap.attrs.transformer.impl
login.create.account.allow.custom.password
login.events.post
login.events.pre
logout.events.post
logout.events.pre
mail.hook.impl
my.places.show.community.private.sites.with.no.layouts
my.places.show.community.public.sites.with.no.layouts
my.places.show.organization.private.sites.with.no.layouts
my.places.show.organization.public.sites.with.no.layouts
my.places.show.user.private.sites.with.no.layouts
my.places.show.user.public.sites.with.no.layouts
passwords.passwordpolicytoolkit.generator
passwords.passwordpolicytoolkit.static
servlet.session.create.events
servlet.session.destroy.events
servlet.service.events.post
servlet.service.events.pre
session.phishing.protected.attributes
terms.of.use.required
theme.css.fast.load
theme.images.fast.load
upgrade.processes
users.email.address.generator
users.email.address.required
users.full.name.validator
users.screen.name.always.autogenerate
users.screen.name.generator
users.screen.name.validator
value.object.listener.*

What’s happening?
As you can see, hooks can be standalone plugins, where one XML file is required liferay-hook.xml. Or hooks can work together with portlets, where simply adding one XML file liferay-hook.xml.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hook PUBLIC "-//Liferay//DTD Hook 6.0.0//EN" "http://www.liferay.com/dtd/liferay-hook_6_0_0.dtd">
<hook>
    <portal-properties>portal.properties</portal-properties>
    <language-properties>content/Language_en.properties</language-properties>
    <custom-jsp-dir>/META-INF/custom_jsps</custom-jsp-dir>
</hook>
Portal Properties Hooks
Through portal properties hooks, we could change certain configuration properties dynamically and inject behaviour into the hooks defined in the portal.properties file. All of the hooks that we have discussed above will revert, and their targeted functionality will be disabled immediately as soon as they are un-deployed from the portal. Also, each type of hook can easily be disabled via the portal.properties file.
Note that a portal.properties file must exist in the plugin hook's WEB-INF/classes folder if portal properties hooks are enabled. Plugin hooks can override the properties like dl.hook.impl, mail.hook.impl, image.hook.impl, etc. To override these properties, add these properties to a portal.properties file in the plugin hook's WEB-INF/classes folder.
Language Properties Hooks
Language properties hooks allow us to install new translations or override few words in existing translations. For example, you’re going to rename “Custom Attributes” as “Custom Fileds” in user editing mode or organization editing mode. You can create and folder content under plugin hook’s WEB-INF/classes, and then you could create a properties file Language_en.properties under the plugin hook's WEB-INF/classes/content. Finally, add following line at Language_en.properties.
custom-attributes=Custom Fields
The above code shows that the message key custom-attributes will have display text Custom Fields.
Note that a Language_en.properties file must exist in the plugin hook's WEB-INF/classes/content folder if language properties hooks got enabled.
More interestingly, language properties hooks allow us to install new translations or override few words in existing translations in both a single language and multiple languages. You can specify multiple language properties files at liferay-hook.xml. Therefore, multiple language properties files got supported via hooks. It is a nice feature that multiple language properties files got supported via hooks.
Custom JSPs Hooks
Custom JSP hooks provide a way to easily modify JSP files of the portal without having to alter the core of the portal. A folder /META-INF/custom_jsps must exist in the plugin hook's Root folder if language properties hooks are enabled.
Under the folder /META-INF/custom_jsps, same folder structure like html as that of $PORTAL_ROOT_HOME/html will be used to override portal JSP files with custom JSP files. In runtime, the original JSP like ${name}.jsp or ${name}.jspf will be renamed as ${name}.portal.jsp or ${name}.portal.jspf under $PORTAL_ROOT_HOME/html; custom JSP files ${name}.jsp or ${name}.jspf will get copied to the folder $PORTAL_ROOT_HOME/html.
For example, you’re going to override the view of login portlet. You can put custom JSP file login.jsp of hook plugin at /META-INF/custom_jsps/html/portlet/login. In runtime, the portal will rename the original JSP login.jsp as login.portal.jsp under $PORTAL_ROOT_HOME/html/portlet/login first; and then the portal will copy custom JSP files login.jsp of hook plugin at /META-INF/custom_jsps/html/portlet/login to the folder $PORTAL_ROOT_HOME/html/portlet/login. More interestingly, you can again include renamed original JSP as follows in custom JSP files login.jsp of hook plugin at /META-INF/custom_jsps/html/portlet/login.
<liferay-util:include page="/html/portlet/login/login.portal.jsp" />
Therefore after deploying hook plugin, you would be see both login.jsp and login.portal.jsp under the folder $PORTAL_ROOT_HOME/html/portlet/login.
Portal Service Hooks
Portal service hooks allow us to customize portal services and models. That is, plugin hooks can override services and models. For example, to override UserLocalService, you can add the following in liferay-hook.xml.
<hook>
 <service>
  <service-type>com.liferay.portal.service.UserLocalService</service-type>
  <service-impl>com.ext.hook.service.impl.ExtUserLocalServiceImpl</service-impl>
 </service>
</hook>
As shown in above code, service was specified by tags <service-type> and <service-impl>. The tag <service-type> provides the original service or model in the portal; and the tag <service-impl> provides customize portal service or model, which will override the original service or model in the portal. More interestingly, you would able to specify many tags <service> if in need.
Note that portal service hooks, portal properties hooks and language properties hooks will get inactive when Hook plugins were un-deployed. 
Enhancement
Custom JSP hooks provide a way to easily modify JSP files of the portal without having to alter the core of the portal. In runtime, the original JSP like ${name}.jsp or ${name}.jspf will be renamed as ${name}.portal.jsp or ${name}.portal.jspf under $PORTAL_ROOT_HOME/html. When hook plugin got un-deployed, the original JSPs should get rolled back. For example, considering custom JSP on logon view, when hook plugin got un-deployed, the portal should delete the JSP login.jsp under $PORTAL_ROOT_HOME/html/portlet/login, and rename login.portal.jsp as login.jsp under $PORTAL_ROOT_HOME/html/portlet/login. This is a nice feature that we could be able to restore the original JSPs of the portal when hook plugin got un-deployed.
And what happens when you deploy two hooks that override the same JSP file? It's currently unsupported for hooks to change the same JSP file. You need to check the hooks for collision; you can use a separate repository for handling this. If you have a collision, the last deployed JSP will be used, but it should be done with care as the order of deployment is not guaranteed.   The hooks should be smart to handle it – this feature is highly expected, too.
As you can see, there are five different kinds of plugins: portlet, theme, layout template, web and ext. For more details, refer to chapter 12 Search, WAP, CRM, Widgets, Reporting and Auditing of the book: Liferay Portal 6 Enterprise Intranets. Ideally one plugin should contain only one kind of plugin like web, ext, theme, hook, and layout template. But the plugin portlet can contain many portlets plus hook optionally, for example the plugin so-portlet included several portlets and a hook.