RubyGems - caterpillar - Versions diffs - 1.4.4 → 1.6.0 - Mend

caterpillar 1.4.4 → 1.6.0

Files changed (62) hide show

data/.gitignore +9 -0
data/ChangeLog +27 -0
data/MIT-LICENSE +0 -4
data/README.rdoc +3 -3
data/Rakefile +6 -22
data/caterpillar.gemspec +28 -0
data/generators/caterpillar/caterpillar_generator.rb +12 -4
data/generators/caterpillar/templates/config/portlets.rb +10 -2
data/generators/caterpillar/templates/stylesheets/portlet_test_bench/main.css +2 -2
data/init.rb +20 -8
data/lib/caterpillar.rb +33 -27
data/lib/caterpillar/config.rb +3 -1
data/lib/caterpillar/helpers/liferay.rb +129 -132
data/lib/caterpillar/helpers/portlet.rb +41 -0
data/lib/caterpillar/liferay.rb +2 -3
data/lib/caterpillar/navigation.rb +2 -4
data/lib/caterpillar/parser.rb +1 -5
data/lib/caterpillar/portlet.rb +20 -19
data/lib/caterpillar/portlet_support.rb +9 -22
data/lib/caterpillar/security.rb +20 -42
data/lib/caterpillar/task.rb +17 -36
data/lib/caterpillar/usage.rb +14 -10
data/lib/caterpillar/util.rb +1 -1
data/lib/java/rails-portlet-0.12.0.jar +0 -0
data/lib/rails_gem_chooser.rb +14 -7
data/lib/web/portlet.rb +1 -1
data/portlet_test_bench/controllers/caterpillar/application.rb +0 -5
data/portlet_test_bench/controllers/caterpillar/junit_controller.rb +30 -9
data/portlet_test_bench/controllers/caterpillar/liferay_controller.rb +13 -3
data/portlet_test_bench/controllers/caterpillar/session_controller.rb +3 -0
data/portlet_test_bench/controllers/caterpillar/xhr_controller.rb +12 -1
data/portlet_test_bench/views/caterpillar/application/_back_to_menu.html.erb +1 -1
data/portlet_test_bench/views/caterpillar/application/index.html.erb +8 -1
data/portlet_test_bench/views/caterpillar/application/portlet_test_bench.html.erb +26 -8
data/portlet_test_bench/views/caterpillar/css/background.html.erb +4 -1
data/portlet_test_bench/views/caterpillar/css/simple.html.erb +13 -9
data/portlet_test_bench/views/caterpillar/liferay/session_variables.html.erb +3 -12
data/portlet_test_bench/views/caterpillar/session/cookies.html.erb +5 -0
data/portlet_test_bench/views/caterpillar/session/namespace.html.erb +14 -0
data/portlet_test_bench/views/caterpillar/xhr/resource.html.erb +15 -0
data/portlet_test_bench/views/caterpillar/xhr/time.html.erb +7 -6
data/spec/app1/config/routes.rb +3 -0
data/spec/app2/config/routes.rb +7 -0
data/spec/app3/config/routes.rb +5 -0
data/spec/caterpillar/helper_spec.rb +69 -0
data/spec/caterpillar/task_spec.rb +192 -0
data/spec/spec.opts +5 -0
data/spec/spec_helper.rb +44 -0
data/test/README +4 -0
data/test/dtd/liferay-display_5_1_0.dtd +44 -44
data/test/dtd/liferay-display_5_2_0.dtd +44 -44
data/test/dtd/liferay-display_6_0_0.dtd +44 -44
data/test/dtd/liferay-portlet-app_5_1_0.dtd +582 -582
data/test/dtd/liferay-portlet-app_5_2_0.dtd +642 -642
data/test/dtd/liferay-portlet-app_6_0_0.dtd +730 -730
data/test/dtd/portlet-app_2_0.xsd +830 -830
data/test/liferay_helpers_test.rb +94 -7
data/test/portlet_support_test.rb +0 -18
data/test/portlets_test.rb +6 -11
data/test/xml_test.rb +4 -14
metadata +53 -31
data/lib/java/rails-portlet-0.10.1.jar +0 -0

data/test/dtd/liferay-portlet-app_5_2_0.dtd CHANGED

@@ -1,643 +1,643 @@
-<!--
-This is the DTD for the Portlet Application parameters that are specific to
-Liferay Portal.
-<!DOCTYPE liferay-portlet-app PUBLIC
-	"-//Liferay//DTD Portlet Application 5.2.0//EN"
-	"http://www.liferay.com/dtd/liferay-portlet-app_5_2_0.dtd">
--->
-<!--
-The liferay-portlet-app element is the root of the deployment descriptor for
-a Liferay portlet application.
--->
-<!ELEMENT liferay-portlet-app (portlet*, role-mapper*, custom-user-attribute*)>
-<!--
-The portlet element contains the declarative data of a portlet.
--->
-<!ELEMENT portlet (portlet-name, icon?, virtual-path?, struts-path?,
-configuration-path?, configuration-action-class?, indexer-class?,
-open-search-class?, scheduler-class?, portlet-url-class?,
-friendly-url-mapper-class?, url-encoder-class?, portlet-data-handler-class?,
-portlet-layout-listener-class?, poller-processor-class?,
-pop-message-listener-class?, social-activity-interpreter-class?,
-social-request-interpreter-class?, webdav-storage-token?, webdav-storage-class?,
-control-panel-entry-category?, control-panel-entry-weight?,
-control-panel-entry-class?, preferences-company-wide?,
-preferences-unique-per-layout?, preferences-owned-by-group?,
-use-default-template?, show-portlet-access-denied?, show-portlet-inactive?,
-action-url-redirect?, restore-current-view?, maximize-edit?, maximize-help?,
-pop-up-print?, layout-cacheable?, instanceable?, scopeable?,
-user-principal-strategy?, private-request-attributes?,
-private-session-attributes?, render-weight?, ajaxable?, header-portal-css*,
-header-portlet-css*, header-portal-javascript*, header-portlet-javascript*,
-footer-portal-css*, footer-portlet-css*, footer-portal-javascript*,
-footer-portlet-javascript*, css-class-wrapper?, facebook-integration?,
-add-default-resource?, system?, active?, include?)>
-<!--
-The portlet-name element contains the unique name of the portlet. This name must
-match the portlet-name specified in portlet.xml.
--->
-<!ELEMENT portlet-name (#PCDATA)>
-<!--
-The icon element specifies an image that represents the portlet.
--->
-<!ELEMENT icon (#PCDATA)>
-<!--
-The virtual-path value sets the virtual path used to override the default
-servlet context path.
-For example, suppose your portlet is deployed to the servlet path
-"/test-portlet". By default, the portal will return "/test-portlet" for the
-servlet context path. You can override it by setting virtual-path to "/virtual"
-and have the portal return "/virtual" for the servlet context path.
-The default value is "" which means this is not used.
--->
-<!ELEMENT virtual-path (#PCDATA)>
-<!--
-Supppose the struts-path value is "mail". This tells the portal that all
-requests with the path mail/* are considered part of this portlet's scope. Users
-who request paths that match mail/* will only be granted access if they also
-have access to this portlet. This is true for both portlet requests and regular
-servlet requests.
--->
-<!ELEMENT struts-path (#PCDATA)>
-<!--
-The configuration-path value is no longer available. Use
-configuration-action-class instead.
--->
-<!ELEMENT configuration-path (#PCDATA)>
-<!--
-The configuration-action-class value must be a class that implements
-com.liferay.portal.kernel.portlet.ConfigurationAction and is called to allow
-users to configure the portlet at runtime.
-See:
-http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portlet/messageboards/action/ConfigurationActionImpl.html
--->
-<!ELEMENT configuration-action-class (#PCDATA)>
-<!--
-The indexer-class value must be a class that implements
-com.liferay.portal.kernel.search.Indexer and is called to create or update a
-search index for the portlet.
-See:
-http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portlet/messageboards/util/Indexer.html
-http://docs.liferay.com/portal/5.2/javadocs/portal-kernel/com/liferay/portal/kernel/search/Indexer.html
-http://lucene.apache.org
--->
-<!ELEMENT indexer-class (#PCDATA)>
-<!--
-The open-search-class value must be a class that implements
-com.liferay.portal.kernel.search.OpenSearch and is called to get search results
-in the OpenSearch 1.1 standard.
-See:
-http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portlet/alfrescocontent/util/OpenSearch.html
-http://docs.liferay.com/portal/5.2/javadocs/portal-kernel/com/liferay/portal/kernel/search/OpenSearch.html
-http://www.opensearch.org
--->
-<!ELEMENT open-search-class (#PCDATA)>
-<!--
-The scheduler-class value must be a class that implements
-com.liferay.portal.kernel.job.Scheduler and is called to schedule jobs for this
-portlet.
-See:
-http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portlet/calendar/job/CalendarScheduler.html
-http://docs.liferay.com/portal/5.2/javadocs/portal-kernel/com/liferay/portal/kernel/job/Scheduler.html
-http://www.opensymphony.com/quartz
--->
-<!ELEMENT scheduler-class (#PCDATA)>
-<!--
-The portlet-url-class value must be a class that extends
-com.liferay.portlet.PortletURLImplWrapper. Set this class to override the
-default portlet URL implementation.
-See:
-http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portal/struts/StrutsActionPortletURL.html
--->
-<!ELEMENT portlet-url-class (#PCDATA)>
-<!--
-The friendly-url-mapper-class value must be a class that implements
-com.liferay.portal.kernel.portlet.FriendlyURLMapper. Use this if content inside
-a portlet needs to have a friendly URL. See the Message Boards portlet for an
-example of its uses.
-See:
-http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portlet/messageboards/MBFriendlyURLMapper.html
-http://docs.liferay.com/portal/5.2/javadocs/portal-kernel/com/liferay/portal/kernel/portlet/FriendlyURLMapper.html
--->
-<!ELEMENT friendly-url-mapper-class (#PCDATA)>
-<!--
-The url-encoder-class value must be a class that implements
-com.liferay.portal.kernel.servlet.URLEncoder. Use this to set a custom
-URLEncoder that is used by the RenderResponse class to implement the encodeURL
-method. This is useful if you need to add custom logic to rewrite URLs.
--->
-<!ELEMENT url-encoder-class (#PCDATA)>
-<!--
-The portlet-data-handler-class value must be a class that implements
-com.liferay.portal.kernel.lar.PortletDataHandler and is called when archiving
-tasks are run.
-See:
-http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portlet/journal/lar/PortletDataHandlerImpl.html
-http://docs.liferay.com/portal/5.2/javadocs/portal-kernel/com/liferay/portal/kernel/lar/PortletDataHandler.html
--->
-<!ELEMENT portlet-data-handler-class (#PCDATA)>
-<!--
-The portlet-layout-listener-class value must be a class that implements
-com.liferay.portal.kernel.portlet.PortletLayoutListener and is called when a portlet
-is added, moved, or removed from a layout.
-See:
-http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portlet/journalcontent/JournalContentPortletLayoutListener.html
-http://docs.liferay.com/portal/5.2/javadocs/portal-kernel/com/liferay/portal/kernel/portlet/PortletLayoutListener.html
--->
-<!ELEMENT portlet-layout-listener-class (#PCDATA)>
-<!--
-The poller-processor-class value must be a class that implements
-com.liferay.portal.kernel.poller.PollerProcessor and is triggered by the
-JavaScript class Liferay.Poller. It allows a portlet to use polling to be
-notified of data changes. See the Chat portlet for a real world implementation.
-See:
-http://docs.liferay.com/portal/5.2/javadocs/portal-kernel/com/liferay/portal/kernel/poller/PollerProcessor.html
--->
-<!ELEMENT poller-processor-class (#PCDATA)>
-<!--
-The pop-message-listener-class value must be a class that implements
-com.liferay.portal.kernel.pop.MessageListener and is called when processing
-emails.
-See:
-http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portlet/messageboards/pop/MessageListenerImpl.html
-http://docs.liferay.com/portal/5.2/javadocs/portal-kernel/com/liferay/portal/kernel/pop/MessageListener.html
--->
-<!ELEMENT pop-message-listener-class (#PCDATA)>
-<!--
-The social-activity-interpreter-class value must be a class that implements
-com.liferay.portlet.social.model.SocialActivityInterpreter and is called to
-interpret activities into friendly messages that are easily understandable by a
-human being.
-See:
-http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portlet/messageboards/social/MBActivityInterpreter.html
-http://docs.liferay.com/portal/5.2/javadocs/portal-service/com/liferay/portlet/social/model/SocialActivityInterpreter.html
--->
-<!ELEMENT social-activity-interpreter-class (#PCDATA)>
-<!--
-The social-request-interpreter-class value must be a class that implements
-com.liferay.portlet.social.model.SocialRequestInterpreter and is called to
-interpret requests into friendly messages that are easily understandable by a
-human being.
-See:
-http://docs.liferay.com/portal/5.2/javadocs/portal-service/com/liferay/portlet/social/model/SocialRequestInterpreter.html
--->
-<!ELEMENT social-request-interpreter-class (#PCDATA)>
-<!--
-The webdav-storage-token value is the WebDAV directory name for data managed by
-this portlet.
-See:
-http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portlet/documentlibrary/webdav/DLWebDAVStorageImpl.html
--->
-<!ELEMENT webdav-storage-token (#PCDATA)>
-<!--
-The webdav-storage-class value must be a class that implements
-com.liferay.portal.webdav.WebDAVStorage and allows data to be exposed via the
-WebDAV protocol.
-See:
-http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portlet/documentlibrary/webdav/DLWebDAVStorageImpl.html
--->
-<!ELEMENT webdav-storage-class (#PCDATA)>
-<!--
-Set the control-panel-entry-category value to "my", "content", "portal" or
-"server" to make this portlet available in the Control Panel under that
-category.
--->
-<!ELEMENT control-panel-entry-category (#PCDATA)>
-<!--
-Set the control-panel-entry-weight value to a double number to control the
-position of the entry within its Control Panel category. Higher values mean
-that the entry will appear lower in the Control Panel menu.
--->
-<!ELEMENT control-panel-entry-weight (#PCDATA)>
-<!--
-The control-panel-entry-class value must be a class that implements
-com.liferay.portlet.ControlPanelEntry and is called by the Control Panel to
-decide whether the portlet should be shown to a specific user in a specific
-context. The default value is set in portal.properties.
-See:
-http://docs.liferay.com/portal/5.2/javadocs/portal-service/com/liferay/portlet/ControlPanelEntry.html
--->
-<!ELEMENT control-panel-entry-class (#PCDATA)>
-<!--
-Set the preferences-company-wide value to true if the preferences for the
-portlet are across the entire company. Setting this value to true means
-the value for preferences-unique-per-layout and preferences-owned-by-group are
-not used. The default value is false.
-For example, an administrator could set the preferences to an Announcements
-portlet that would save a message in the portlet's preferences. This message
-would then be used across all pages for that company. The portlet must not be
-instanceable because instanceable portlets have uniquely generated portlet ids.
-The default behavior of the bundled Announcements portlet sets the instanceable
-value to true so that normal users cannot create company wide messages. A future
-release would include permissions for the edit mode versus the view mode which
-would allow an administrator to set the message while users would just view the
-message.
--->
-<!ELEMENT preferences-company-wide (#PCDATA)>
-<!--
-Set the preferences-unique-per-layout value to true if the preferences for the
-portlet are unique across all pages. If set to false, the preferences for the
-portlet are shared across all pages. The default value is true.
-The preferences-unique-per-layout element is used in combination with the
-preferences-owned-by-group element. See the comments for the
-preferences-owned-by-group element for more information.
--->
-<!ELEMENT preferences-unique-per-layout (#PCDATA)>
-<!--
-Set the preferences-owned-by-group value to true if the preferences for the
-portlet are owned by the group when the portlet is shown in a group page. If
-set to false, the preferences are owned by the user at all times. The default
-value is true.
-Suppose the Stocks portlet has preferences-unique-per-layout set to true and
-preferences-owned-by-group set to false. Users can set a different list of
-stocks for every personal page. Users can set a different list of stocks for
-every community page.
-Suppose the Stocks portlet has preferences-unique-per-layout set to false and
-preferences-owned-by-group set to false. Users can set one list of stocks to be
-shared across all personal pages. Users can set one list of stocks to be shared
-across a community's set of pages.
-Suppose the Stocks portlet has preferences-unique-per-layout set to true and
-preferences-owned-by-group set to true. Users can set a different list of stocks
-for every personal page. Administrators set the portlet preferences for users in
-a community page. Administrators can set a different list of stocks for every
-community page that are then shared by all users within a community.
-Suppose the Stocks portlet has preferences-unique-per-layout set to false and
-preferences-owned-by-group set to true. Users can set one list of stocks to be
-shared across all personal pages. Administrators set the portlet preferences for
-users in a community page. Administrators can set one list of stocks to be
-shared by all users across a community's set of pages.
--->
-<!ELEMENT preferences-owned-by-group (#PCDATA)>
-<!--
-Set the use-default-template value to true if the portlet uses the default
-template to decorate and wrap content. Setting this to false allows the
-developer to own and maintain the portlet's entire outputted content. The
-default value is true.
-The most common use of this is if you want the portlet to look different from
-the other portlets or if you want the portlet to not have borders around the
-outputted content.
--->
-<!ELEMENT use-default-template (#PCDATA)>
-<!--
-Set the show-portlet-access-denied value to true if users are shown the portlet
-with an access denied message if they do not have access to the portlet. If set
-to false, users are never shown the portlet if they do not have access to the
-portlet. The default value is set in portal.properties.
-See:
-http://www.liferay.com/page/guest/documentation/development/properties
--->
-<!ELEMENT show-portlet-access-denied (#PCDATA)>
-<!--
-Set the show-portlet-inactive value to true if users are shown the portlet
-with an inactive message if the portlet is inactive. If set to false, users are
-never shown the portlet if the portlet is inactive. The default value is set in
-portal.properties.
-http://www.liferay.com/page/guest/documentation/development/properties
--->
-<!ELEMENT show-portlet-inactive (#PCDATA)>
-<!--
-Set the action-url-redirect value to true if an action URL for this portlet
-should cause an auto redirect. This helps prevent double submits. The default
-value is false.
--->
-<!ELEMENT action-url-redirect (#PCDATA)>
-<!--
-Set the restore-current-view value to true if the portlet restores to the
-current view when toggling between maximized and normal states. If set to false,
-the portlet will reset the current view when toggling between maximized and
-normal states. The default value is true.
--->
-<!ELEMENT restore-current-view (#PCDATA)>
-<!--
-Set the maximize-edit value to true if the portlet goes into the maximized state
-when the user goes into the edit mode. This only affects the default portal
-icons and not what may be programmatically set by the portlet developer.
-The default value is false.
--->
-<!ELEMENT maximize-edit (#PCDATA)>
-<!--
-Set the maximize-help value to true if the portlet goes into the maximized state
-when the user goes into the help mode. This only affects the default portal
-icons and not what may be programmatically set by the portlet developer.
-The default value is false.
--->
-<!ELEMENT maximize-help (#PCDATA)>
-<!--
-Set the pop-up-print value to true if the portlet goes into the pop up state
-when the user goes into the print mode. This only affects the default portal
-icons and not what may be programmatically set by the portlet developer.
-The default value is true.
--->
-<!ELEMENT pop-up-print (#PCDATA)>
-<!--
-Set the layout-cacheable flag to true if the data contained in this portlet can
-will never change unless the layout or Journal portlet entry is changed.
--->
-<!ELEMENT layout-cacheable (#PCDATA)>
-<!--
-Set the instanceable value to true if the portlet can appear multiple times on a
-page. If set to false, the portlet can only appear once on a page. The default
-value is false.
--->
-<!ELEMENT instanceable (#PCDATA)>
-<!--
-If the scopeable is set to true, an administrator will be able to configure the
-scope of the data of the portlet to either the current community (default),
-the current layout, or the scope of any other layout of the community that
-already exists. Portlets that want to support this must be programmed to obtain
-the proper scope group id according to the configuration and scope their data
-accordingly. The default is false.
--->
-<!ELEMENT scopeable (#PCDATA)>
-<!--
-Set the user-principal-strategy value to either "userId" or "screenName".
-Calling request.getRemoteUser() will normally return the user id. However, some
-portlets may need the user principal returned to be screen name instead.
--->
-<!ELEMENT user-principal-strategy (#PCDATA)>
-<!--
-Set the private-request-attributes value to true if the portlet does not share
-request attributes with the portal or any other portlet. The default value is
-true. The property "request.shared.attributes" in portal.properties specifies
-which request attributes are shared even when the private-request-attributes
-value is true.
--->
-<!ELEMENT private-request-attributes (#PCDATA)>
-<!--
-Set the private-session-attributes value to true if the portlet does not share
-session attributes with the portal. The default value is true. The property
-"session.shared.attributes" in portal.properties specifies which session
-attributes are shared even when the private-session-attributes value is true.
--->
-<!ELEMENT private-session-attributes (#PCDATA)>
-<!--
-The default value of render-weight is 1. If set to a value less than 1, the
-portlet is rendered in parallel. If set to a value of 1 or greater, then the
-portlet is rendered serially. Portlets with a greater render weight have greater
-priority and will be rendered before portlets with a lower render weight.
-If the ajaxable value is set to false, then render-weight is always set to 1
-if it is set to a value less than 1. This means ajaxable can override
-render-weight if ajaxable is set to false.
--->
-<!ELEMENT render-weight (#PCDATA)>
-<!--
-The default value of ajaxable is true. If set to false, then this portlet can
-never be displayed via Ajax.
--->
-<!ELEMENT ajaxable (#PCDATA)>
-<!--
-Set the path of CSS that will be referenced in the page's header relative to the
-portal's context path.
--->
-<!ELEMENT header-portal-css (#PCDATA)>
-<!--
-Set the path of CSS that will be referenced in the page's header relative to the
-portlet's context path.
--->
-<!ELEMENT header-portlet-css (#PCDATA)>
-<!--
-Set the path of JavaScript that will be referenced in the page's header relative
-to the portal's context path.
--->
-<!ELEMENT header-portal-javascript (#PCDATA)>
-<!--
-Set the path of JavaScript that will be referenced in the page's header relative
-to the portlet's context path.
--->
-<!ELEMENT header-portlet-javascript (#PCDATA)>
-<!--
-Set the path of CSS that will be referenced in the page's footer relative to the
-portal's context path.
--->
-<!ELEMENT footer-portal-css (#PCDATA)>
-<!--
-Set the path of CSS that will be referenced in the page's footer relative to the
-portlet's context path.
--->
-<!ELEMENT footer-portlet-css (#PCDATA)>
-<!--
-Set the path of JavaScript that will be referenced in the page's footer relative
-to the portal's context path.
--->
-<!ELEMENT footer-portal-javascript (#PCDATA)>
-<!--
-Set the path of JavaScript that will be referenced in the page's footer relative
-to the portlet's context path.
--->
-<!ELEMENT footer-portlet-javascript (#PCDATA)>
-<!--
-Set name of the CSS class that will be injected in the DIV that wraps this
-portlet.
--->
-<!ELEMENT css-class-wrapper (#PCDATA)>
-<!--
-Set the facebook-integration value to either "fbml" or "iframe". The default
-value is "iframe" because IFrame integration will work without requiring any
-changes to your code. See the Message Boards portlet for minor changes that were
-made to make it FBML compliant. Note that the Liferay tag libraries already
-output FBML automatically if a request is made by Facebook.
--->
-<!ELEMENT facebook-integration (#PCDATA)>
-<!--
-If the add-default-resource value is set to false, and the portlet does not
-belong to the page but has been dynamically added, then the user will see that
-he does not have permissions to view the portlet. If the add-default-resource
-value is set to true, the default portlet resources and permissions are added to
-the page. The user can then view the portlet. Most portlets are harmless and can
-benefit from this flexibility. However, to prevent security loop holes, the
-default value is false.
-The properties "portlet.add.default.resource.check.enabled" and
-"portlet.add.default.resource.check.whitelist" in portal.properties allow
-security checks to be configured around this behavior.
--->
-<!ELEMENT add-default-resource (#PCDATA)>
-<!--
-Set the system value to true if the portlet is a system portlet that a user
-cannot manually add to their page. The default value is false.
--->
-<!ELEMENT system (#PCDATA)>
-<!--
-Set the active value to true if the portlet is active and available to users.
-If set to false, the portlet will not be active or available to users. The
-default value is true.
-This value can be changed at runtime via the Admin portlet.
--->
-<!ELEMENT active (#PCDATA)>
-<!--
-Set the include value to true to if the portlet is available to the portal. If
-set to false, the portlet is not available to the portal. The default value is
-true.
-Portlets that are not included as part of the portal are never available to the
-user to be made active or inactive. As far the user knows, the portlets do not
-even exist in the system. This allows the Liferay developers to bundle a lot of
-portlets in one core package, and yet allow custom deployments to turn on or off
-individual portlets or sets of portlets. This follows the Siebel and Microsoft
-model of bundling everything in one core package, but using XML configuration or
-registry settings to turn on and off features or sets of features.
-We do not recommend that custom deployers modify the core source by removing
-specific portlets because this prevents an easy upgrade process in the future.
-The best way to turn on and off portlets is to set the include element. The
-advantage of this way of doing things is that it becomes very easy to deploy
-Liferay. All features are available in one package. The disadvantage is that by
-not utilizing all of the portlets, you are wasting disk space and may even take
-a small but static memory footprint. However, we feel that the extra disk space
-and memory usage is a cheap price to pay in order to provide an easy
-installation and upgrade path.
--->
-<!ELEMENT include (#PCDATA)>
-<!--
-The role-mapper contains two names specified by role-name and role-link. The
-role-name value must be a role specified in portlet.xml. The role-link value
-must be the name of a Liferay role that exists in the database. The role-mapper
-element pairs up these two values to map roles from portlet.xml to roles in
-the Liferay database.
-This is needed because Liferay roles may contain spaces whereas roles in
-portlet.xml cannot contain spaces. This also adds extra flexibility where the
-portlet vendor does not need to have any knowledge about Liferay's roles.
--->
-<!ELEMENT role-mapper (role-name, role-link)>
-<!--
-See the comments in role-mapper element.
--->
-<!ELEMENT role-name (#PCDATA)>
-<!--
-See the comments in role-mapper element.
--->
-<!ELEMENT role-link (#PCDATA)>
-<!--
-The custom-user-attribute contains a list of names that are retrieved using a
-custom class that extends com.liferay.portlet.CustomUserAttributes.
-Download the sample hot deployable portlet WAR named test.war. Look for the
-class com.sample.strutsliferay.portlet.SampleUserAttributes to see how it
-associates the custom user attribute "user.name.test" with the value
-"Test Name". This class could be modified to read custom user attributes from
-another datasource that may be a database, a LDAP server, or a web service.
-See:
-http://www.liferay.com/page/guest/documentation/development/hot_deploy
--->
-<!ELEMENT custom-user-attribute (name+, custom-class)>
-<!--
-See the comments in custom-user-attribute element.
--->
-<!ELEMENT name (#PCDATA)>
-<!--
-See the comments in custom-user-attribute element.
--->
+<!--
+This is the DTD for the Portlet Application parameters that are specific to
+Liferay Portal.
+<!DOCTYPE liferay-portlet-app PUBLIC
+	"-//Liferay//DTD Portlet Application 5.2.0//EN"
+	"http://www.liferay.com/dtd/liferay-portlet-app_5_2_0.dtd">
+-->
+<!--
+The liferay-portlet-app element is the root of the deployment descriptor for
+a Liferay portlet application.
+-->
+<!ELEMENT liferay-portlet-app (portlet*, role-mapper*, custom-user-attribute*)>
+<!--
+The portlet element contains the declarative data of a portlet.
+-->
+<!ELEMENT portlet (portlet-name, icon?, virtual-path?, struts-path?,
+configuration-path?, configuration-action-class?, indexer-class?,
+open-search-class?, scheduler-class?, portlet-url-class?,
+friendly-url-mapper-class?, url-encoder-class?, portlet-data-handler-class?,
+portlet-layout-listener-class?, poller-processor-class?,
+pop-message-listener-class?, social-activity-interpreter-class?,
+social-request-interpreter-class?, webdav-storage-token?, webdav-storage-class?,
+control-panel-entry-category?, control-panel-entry-weight?,
+control-panel-entry-class?, preferences-company-wide?,
+preferences-unique-per-layout?, preferences-owned-by-group?,
+use-default-template?, show-portlet-access-denied?, show-portlet-inactive?,
+action-url-redirect?, restore-current-view?, maximize-edit?, maximize-help?,
+pop-up-print?, layout-cacheable?, instanceable?, scopeable?,
+user-principal-strategy?, private-request-attributes?,
+private-session-attributes?, render-weight?, ajaxable?, header-portal-css*,
+header-portlet-css*, header-portal-javascript*, header-portlet-javascript*,
+footer-portal-css*, footer-portlet-css*, footer-portal-javascript*,
+footer-portlet-javascript*, css-class-wrapper?, facebook-integration?,
+add-default-resource?, system?, active?, include?)>
+<!--
+The portlet-name element contains the unique name of the portlet. This name must
+match the portlet-name specified in portlet.xml.
+-->
+<!ELEMENT portlet-name (#PCDATA)>
+<!--
+The icon element specifies an image that represents the portlet.
+-->
+<!ELEMENT icon (#PCDATA)>
+<!--
+The virtual-path value sets the virtual path used to override the default
+servlet context path.
+For example, suppose your portlet is deployed to the servlet path
+"/test-portlet". By default, the portal will return "/test-portlet" for the
+servlet context path. You can override it by setting virtual-path to "/virtual"
+and have the portal return "/virtual" for the servlet context path.
+The default value is "" which means this is not used.
+-->
+<!ELEMENT virtual-path (#PCDATA)>
+<!--
+Supppose the struts-path value is "mail". This tells the portal that all
+requests with the path mail/* are considered part of this portlet's scope. Users
+who request paths that match mail/* will only be granted access if they also
+have access to this portlet. This is true for both portlet requests and regular
+servlet requests.
+-->
+<!ELEMENT struts-path (#PCDATA)>
+<!--
+The configuration-path value is no longer available. Use
+configuration-action-class instead.
+-->
+<!ELEMENT configuration-path (#PCDATA)>
+<!--
+The configuration-action-class value must be a class that implements
+com.liferay.portal.kernel.portlet.ConfigurationAction and is called to allow
+users to configure the portlet at runtime.
+See:
+http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portlet/messageboards/action/ConfigurationActionImpl.html
+-->
+<!ELEMENT configuration-action-class (#PCDATA)>
+<!--
+The indexer-class value must be a class that implements
+com.liferay.portal.kernel.search.Indexer and is called to create or update a
+search index for the portlet.
+See:
+http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portlet/messageboards/util/Indexer.html
+http://docs.liferay.com/portal/5.2/javadocs/portal-kernel/com/liferay/portal/kernel/search/Indexer.html
+http://lucene.apache.org
+-->
+<!ELEMENT indexer-class (#PCDATA)>
+<!--
+The open-search-class value must be a class that implements
+com.liferay.portal.kernel.search.OpenSearch and is called to get search results
+in the OpenSearch 1.1 standard.
+See:
+http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portlet/alfrescocontent/util/OpenSearch.html
+http://docs.liferay.com/portal/5.2/javadocs/portal-kernel/com/liferay/portal/kernel/search/OpenSearch.html
+http://www.opensearch.org
+-->
+<!ELEMENT open-search-class (#PCDATA)>
+<!--
+The scheduler-class value must be a class that implements
+com.liferay.portal.kernel.job.Scheduler and is called to schedule jobs for this
+portlet.
+See:
+http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portlet/calendar/job/CalendarScheduler.html
+http://docs.liferay.com/portal/5.2/javadocs/portal-kernel/com/liferay/portal/kernel/job/Scheduler.html
+http://www.opensymphony.com/quartz
+-->
+<!ELEMENT scheduler-class (#PCDATA)>
+<!--
+The portlet-url-class value must be a class that extends
+com.liferay.portlet.PortletURLImplWrapper. Set this class to override the
+default portlet URL implementation.
+See:
+http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portal/struts/StrutsActionPortletURL.html
+-->
+<!ELEMENT portlet-url-class (#PCDATA)>
+<!--
+The friendly-url-mapper-class value must be a class that implements
+com.liferay.portal.kernel.portlet.FriendlyURLMapper. Use this if content inside
+a portlet needs to have a friendly URL. See the Message Boards portlet for an
+example of its uses.
+See:
+http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portlet/messageboards/MBFriendlyURLMapper.html
+http://docs.liferay.com/portal/5.2/javadocs/portal-kernel/com/liferay/portal/kernel/portlet/FriendlyURLMapper.html
+-->
+<!ELEMENT friendly-url-mapper-class (#PCDATA)>
+<!--
+The url-encoder-class value must be a class that implements
+com.liferay.portal.kernel.servlet.URLEncoder. Use this to set a custom
+URLEncoder that is used by the RenderResponse class to implement the encodeURL
+method. This is useful if you need to add custom logic to rewrite URLs.
+-->
+<!ELEMENT url-encoder-class (#PCDATA)>
+<!--
+The portlet-data-handler-class value must be a class that implements
+com.liferay.portal.kernel.lar.PortletDataHandler and is called when archiving
+tasks are run.
+See:
+http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portlet/journal/lar/PortletDataHandlerImpl.html
+http://docs.liferay.com/portal/5.2/javadocs/portal-kernel/com/liferay/portal/kernel/lar/PortletDataHandler.html
+-->
+<!ELEMENT portlet-data-handler-class (#PCDATA)>
+<!--
+The portlet-layout-listener-class value must be a class that implements
+com.liferay.portal.kernel.portlet.PortletLayoutListener and is called when a portlet
+is added, moved, or removed from a layout.
+See:
+http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portlet/journalcontent/JournalContentPortletLayoutListener.html
+http://docs.liferay.com/portal/5.2/javadocs/portal-kernel/com/liferay/portal/kernel/portlet/PortletLayoutListener.html
+-->
+<!ELEMENT portlet-layout-listener-class (#PCDATA)>
+<!--
+The poller-processor-class value must be a class that implements
+com.liferay.portal.kernel.poller.PollerProcessor and is triggered by the
+JavaScript class Liferay.Poller. It allows a portlet to use polling to be
+notified of data changes. See the Chat portlet for a real world implementation.
+See:
+http://docs.liferay.com/portal/5.2/javadocs/portal-kernel/com/liferay/portal/kernel/poller/PollerProcessor.html
+-->
+<!ELEMENT poller-processor-class (#PCDATA)>
+<!--
+The pop-message-listener-class value must be a class that implements
+com.liferay.portal.kernel.pop.MessageListener and is called when processing
+emails.
+See:
+http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portlet/messageboards/pop/MessageListenerImpl.html
+http://docs.liferay.com/portal/5.2/javadocs/portal-kernel/com/liferay/portal/kernel/pop/MessageListener.html
+-->
+<!ELEMENT pop-message-listener-class (#PCDATA)>
+<!--
+The social-activity-interpreter-class value must be a class that implements
+com.liferay.portlet.social.model.SocialActivityInterpreter and is called to
+interpret activities into friendly messages that are easily understandable by a
+human being.
+See:
+http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portlet/messageboards/social/MBActivityInterpreter.html
+http://docs.liferay.com/portal/5.2/javadocs/portal-service/com/liferay/portlet/social/model/SocialActivityInterpreter.html
+-->
+<!ELEMENT social-activity-interpreter-class (#PCDATA)>
+<!--
+The social-request-interpreter-class value must be a class that implements
+com.liferay.portlet.social.model.SocialRequestInterpreter and is called to
+interpret requests into friendly messages that are easily understandable by a
+human being.
+See:
+http://docs.liferay.com/portal/5.2/javadocs/portal-service/com/liferay/portlet/social/model/SocialRequestInterpreter.html
+-->
+<!ELEMENT social-request-interpreter-class (#PCDATA)>
+<!--
+The webdav-storage-token value is the WebDAV directory name for data managed by
+this portlet.
+See:
+http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portlet/documentlibrary/webdav/DLWebDAVStorageImpl.html
+-->
+<!ELEMENT webdav-storage-token (#PCDATA)>
+<!--
+The webdav-storage-class value must be a class that implements
+com.liferay.portal.webdav.WebDAVStorage and allows data to be exposed via the
+WebDAV protocol.
+See:
+http://docs.liferay.com/portal/5.2/javadocs/portal-impl/com/liferay/portlet/documentlibrary/webdav/DLWebDAVStorageImpl.html
+-->
+<!ELEMENT webdav-storage-class (#PCDATA)>
+<!--
+Set the control-panel-entry-category value to "my", "content", "portal" or
+"server" to make this portlet available in the Control Panel under that
+category.
+-->
+<!ELEMENT control-panel-entry-category (#PCDATA)>
+<!--
+Set the control-panel-entry-weight value to a double number to control the
+position of the entry within its Control Panel category. Higher values mean
+that the entry will appear lower in the Control Panel menu.
+-->
+<!ELEMENT control-panel-entry-weight (#PCDATA)>
+<!--
+The control-panel-entry-class value must be a class that implements
+com.liferay.portlet.ControlPanelEntry and is called by the Control Panel to
+decide whether the portlet should be shown to a specific user in a specific
+context. The default value is set in portal.properties.
+See:
+http://docs.liferay.com/portal/5.2/javadocs/portal-service/com/liferay/portlet/ControlPanelEntry.html
+-->
+<!ELEMENT control-panel-entry-class (#PCDATA)>
+<!--
+Set the preferences-company-wide value to true if the preferences for the
+portlet are across the entire company. Setting this value to true means
+the value for preferences-unique-per-layout and preferences-owned-by-group are
+not used. The default value is false.
+For example, an administrator could set the preferences to an Announcements
+portlet that would save a message in the portlet's preferences. This message
+would then be used across all pages for that company. The portlet must not be
+instanceable because instanceable portlets have uniquely generated portlet ids.
+The default behavior of the bundled Announcements portlet sets the instanceable
+value to true so that normal users cannot create company wide messages. A future
+release would include permissions for the edit mode versus the view mode which
+would allow an administrator to set the message while users would just view the
+message.
+-->
+<!ELEMENT preferences-company-wide (#PCDATA)>
+<!--
+Set the preferences-unique-per-layout value to true if the preferences for the
+portlet are unique across all pages. If set to false, the preferences for the
+portlet are shared across all pages. The default value is true.
+The preferences-unique-per-layout element is used in combination with the
+preferences-owned-by-group element. See the comments for the
+preferences-owned-by-group element for more information.
+-->
+<!ELEMENT preferences-unique-per-layout (#PCDATA)>
+<!--
+Set the preferences-owned-by-group value to true if the preferences for the
+portlet are owned by the group when the portlet is shown in a group page. If
+set to false, the preferences are owned by the user at all times. The default
+value is true.
+Suppose the Stocks portlet has preferences-unique-per-layout set to true and
+preferences-owned-by-group set to false. Users can set a different list of
+stocks for every personal page. Users can set a different list of stocks for
+every community page.
+Suppose the Stocks portlet has preferences-unique-per-layout set to false and
+preferences-owned-by-group set to false. Users can set one list of stocks to be
+shared across all personal pages. Users can set one list of stocks to be shared
+across a community's set of pages.
+Suppose the Stocks portlet has preferences-unique-per-layout set to true and
+preferences-owned-by-group set to true. Users can set a different list of stocks
+for every personal page. Administrators set the portlet preferences for users in
+a community page. Administrators can set a different list of stocks for every
+community page that are then shared by all users within a community.
+Suppose the Stocks portlet has preferences-unique-per-layout set to false and
+preferences-owned-by-group set to true. Users can set one list of stocks to be
+shared across all personal pages. Administrators set the portlet preferences for
+users in a community page. Administrators can set one list of stocks to be
+shared by all users across a community's set of pages.
+-->
+<!ELEMENT preferences-owned-by-group (#PCDATA)>
+<!--
+Set the use-default-template value to true if the portlet uses the default
+template to decorate and wrap content. Setting this to false allows the
+developer to own and maintain the portlet's entire outputted content. The
+default value is true.
+The most common use of this is if you want the portlet to look different from
+the other portlets or if you want the portlet to not have borders around the
+outputted content.
+-->
+<!ELEMENT use-default-template (#PCDATA)>
+<!--
+Set the show-portlet-access-denied value to true if users are shown the portlet
+with an access denied message if they do not have access to the portlet. If set
+to false, users are never shown the portlet if they do not have access to the
+portlet. The default value is set in portal.properties.
+See:
+http://www.liferay.com/page/guest/documentation/development/properties
+-->
+<!ELEMENT show-portlet-access-denied (#PCDATA)>
+<!--
+Set the show-portlet-inactive value to true if users are shown the portlet
+with an inactive message if the portlet is inactive. If set to false, users are
+never shown the portlet if the portlet is inactive. The default value is set in
+portal.properties.
+http://www.liferay.com/page/guest/documentation/development/properties
+-->
+<!ELEMENT show-portlet-inactive (#PCDATA)>
+<!--
+Set the action-url-redirect value to true if an action URL for this portlet
+should cause an auto redirect. This helps prevent double submits. The default
+value is false.
+-->
+<!ELEMENT action-url-redirect (#PCDATA)>
+<!--
+Set the restore-current-view value to true if the portlet restores to the
+current view when toggling between maximized and normal states. If set to false,
+the portlet will reset the current view when toggling between maximized and
+normal states. The default value is true.
+-->
+<!ELEMENT restore-current-view (#PCDATA)>
+<!--
+Set the maximize-edit value to true if the portlet goes into the maximized state
+when the user goes into the edit mode. This only affects the default portal
+icons and not what may be programmatically set by the portlet developer.
+The default value is false.
+-->
+<!ELEMENT maximize-edit (#PCDATA)>
+<!--
+Set the maximize-help value to true if the portlet goes into the maximized state
+when the user goes into the help mode. This only affects the default portal
+icons and not what may be programmatically set by the portlet developer.
+The default value is false.
+-->
+<!ELEMENT maximize-help (#PCDATA)>
+<!--
+Set the pop-up-print value to true if the portlet goes into the pop up state
+when the user goes into the print mode. This only affects the default portal
+icons and not what may be programmatically set by the portlet developer.
+The default value is true.
+-->
+<!ELEMENT pop-up-print (#PCDATA)>
+<!--
+Set the layout-cacheable flag to true if the data contained in this portlet can
+will never change unless the layout or Journal portlet entry is changed.
+-->
+<!ELEMENT layout-cacheable (#PCDATA)>
+<!--
+Set the instanceable value to true if the portlet can appear multiple times on a
+page. If set to false, the portlet can only appear once on a page. The default
+value is false.
+-->
+<!ELEMENT instanceable (#PCDATA)>
+<!--
+If the scopeable is set to true, an administrator will be able to configure the
+scope of the data of the portlet to either the current community (default),
+the current layout, or the scope of any other layout of the community that
+already exists. Portlets that want to support this must be programmed to obtain
+the proper scope group id according to the configuration and scope their data
+accordingly. The default is false.
+-->
+<!ELEMENT scopeable (#PCDATA)>
+<!--
+Set the user-principal-strategy value to either "userId" or "screenName".
+Calling request.getRemoteUser() will normally return the user id. However, some
+portlets may need the user principal returned to be screen name instead.
+-->
+<!ELEMENT user-principal-strategy (#PCDATA)>
+<!--
+Set the private-request-attributes value to true if the portlet does not share
+request attributes with the portal or any other portlet. The default value is
+true. The property "request.shared.attributes" in portal.properties specifies
+which request attributes are shared even when the private-request-attributes
+value is true.
+-->
+<!ELEMENT private-request-attributes (#PCDATA)>
+<!--
+Set the private-session-attributes value to true if the portlet does not share
+session attributes with the portal. The default value is true. The property
+"session.shared.attributes" in portal.properties specifies which session
+attributes are shared even when the private-session-attributes value is true.
+-->
+<!ELEMENT private-session-attributes (#PCDATA)>
+<!--
+The default value of render-weight is 1. If set to a value less than 1, the
+portlet is rendered in parallel. If set to a value of 1 or greater, then the
+portlet is rendered serially. Portlets with a greater render weight have greater
+priority and will be rendered before portlets with a lower render weight.
+If the ajaxable value is set to false, then render-weight is always set to 1
+if it is set to a value less than 1. This means ajaxable can override
+render-weight if ajaxable is set to false.
+-->
+<!ELEMENT render-weight (#PCDATA)>
+<!--
+The default value of ajaxable is true. If set to false, then this portlet can
+never be displayed via Ajax.
+-->
+<!ELEMENT ajaxable (#PCDATA)>
+<!--
+Set the path of CSS that will be referenced in the page's header relative to the
+portal's context path.
+-->
+<!ELEMENT header-portal-css (#PCDATA)>
+<!--
+Set the path of CSS that will be referenced in the page's header relative to the
+portlet's context path.
+-->
+<!ELEMENT header-portlet-css (#PCDATA)>
+<!--
+Set the path of JavaScript that will be referenced in the page's header relative
+to the portal's context path.
+-->
+<!ELEMENT header-portal-javascript (#PCDATA)>
+<!--
+Set the path of JavaScript that will be referenced in the page's header relative
+to the portlet's context path.
+-->
+<!ELEMENT header-portlet-javascript (#PCDATA)>
+<!--
+Set the path of CSS that will be referenced in the page's footer relative to the
+portal's context path.
+-->
+<!ELEMENT footer-portal-css (#PCDATA)>
+<!--
+Set the path of CSS that will be referenced in the page's footer relative to the
+portlet's context path.
+-->
+<!ELEMENT footer-portlet-css (#PCDATA)>
+<!--
+Set the path of JavaScript that will be referenced in the page's footer relative
+to the portal's context path.
+-->
+<!ELEMENT footer-portal-javascript (#PCDATA)>
+<!--
+Set the path of JavaScript that will be referenced in the page's footer relative
+to the portlet's context path.
+-->
+<!ELEMENT footer-portlet-javascript (#PCDATA)>
+<!--
+Set name of the CSS class that will be injected in the DIV that wraps this
+portlet.
+-->
+<!ELEMENT css-class-wrapper (#PCDATA)>
+<!--
+Set the facebook-integration value to either "fbml" or "iframe". The default
+value is "iframe" because IFrame integration will work without requiring any
+changes to your code. See the Message Boards portlet for minor changes that were
+made to make it FBML compliant. Note that the Liferay tag libraries already
+output FBML automatically if a request is made by Facebook.
+-->
+<!ELEMENT facebook-integration (#PCDATA)>
+<!--
+If the add-default-resource value is set to false, and the portlet does not
+belong to the page but has been dynamically added, then the user will see that
+he does not have permissions to view the portlet. If the add-default-resource
+value is set to true, the default portlet resources and permissions are added to
+the page. The user can then view the portlet. Most portlets are harmless and can
+benefit from this flexibility. However, to prevent security loop holes, the
+default value is false.
+The properties "portlet.add.default.resource.check.enabled" and
+"portlet.add.default.resource.check.whitelist" in portal.properties allow
+security checks to be configured around this behavior.
+-->
+<!ELEMENT add-default-resource (#PCDATA)>
+<!--
+Set the system value to true if the portlet is a system portlet that a user
+cannot manually add to their page. The default value is false.
+-->
+<!ELEMENT system (#PCDATA)>
+<!--
+Set the active value to true if the portlet is active and available to users.
+If set to false, the portlet will not be active or available to users. The
+default value is true.
+This value can be changed at runtime via the Admin portlet.
+-->
+<!ELEMENT active (#PCDATA)>
+<!--
+Set the include value to true to if the portlet is available to the portal. If
+set to false, the portlet is not available to the portal. The default value is
+true.
+Portlets that are not included as part of the portal are never available to the
+user to be made active or inactive. As far the user knows, the portlets do not
+even exist in the system. This allows the Liferay developers to bundle a lot of
+portlets in one core package, and yet allow custom deployments to turn on or off
+individual portlets or sets of portlets. This follows the Siebel and Microsoft
+model of bundling everything in one core package, but using XML configuration or
+registry settings to turn on and off features or sets of features.
+We do not recommend that custom deployers modify the core source by removing
+specific portlets because this prevents an easy upgrade process in the future.
+The best way to turn on and off portlets is to set the include element. The
+advantage of this way of doing things is that it becomes very easy to deploy
+Liferay. All features are available in one package. The disadvantage is that by
+not utilizing all of the portlets, you are wasting disk space and may even take
+a small but static memory footprint. However, we feel that the extra disk space
+and memory usage is a cheap price to pay in order to provide an easy
+installation and upgrade path.
+-->
+<!ELEMENT include (#PCDATA)>
+<!--
+The role-mapper contains two names specified by role-name and role-link. The
+role-name value must be a role specified in portlet.xml. The role-link value
+must be the name of a Liferay role that exists in the database. The role-mapper
+element pairs up these two values to map roles from portlet.xml to roles in
+the Liferay database.
+This is needed because Liferay roles may contain spaces whereas roles in
+portlet.xml cannot contain spaces. This also adds extra flexibility where the
+portlet vendor does not need to have any knowledge about Liferay's roles.
+-->
+<!ELEMENT role-mapper (role-name, role-link)>
+<!--
+See the comments in role-mapper element.
+-->
+<!ELEMENT role-name (#PCDATA)>
+<!--
+See the comments in role-mapper element.
+-->
+<!ELEMENT role-link (#PCDATA)>
+<!--
+The custom-user-attribute contains a list of names that are retrieved using a
+custom class that extends com.liferay.portlet.CustomUserAttributes.
+Download the sample hot deployable portlet WAR named test.war. Look for the
+class com.sample.strutsliferay.portlet.SampleUserAttributes to see how it
+associates the custom user attribute "user.name.test" with the value
+"Test Name". This class could be modified to read custom user attributes from
+another datasource that may be a database, a LDAP server, or a web service.
+See:
+http://www.liferay.com/page/guest/documentation/development/hot_deploy
+-->
+<!ELEMENT custom-user-attribute (name+, custom-class)>
+<!--
+See the comments in custom-user-attribute element.
+-->
+<!ELEMENT name (#PCDATA)>
+<!--
+See the comments in custom-user-attribute element.
+-->
 <!ELEMENT custom-class (#PCDATA)>