3:51 p.m.
Author: smumford
Date: 2011-12-08 16:51:37 -0500 (Thu, 08 Dec 2011)
New Revision: 8218
Modified:
epp/docs/branches/5.2/Reference_Guide/en-US/Book_Info.xml
epp/docs/branches/5.2/Reference_Guide/en-US/Revision_History.xml
epp/docs/branches/5.2/Reference_Guide/en-US/extras/Advanced_Development_JCR_lock-manager-config/you.xml
epp/docs/branches/5.2/Reference_Guide/en-US/extras/PortalDevelopment_PortalLifecycle/default160.xml
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/PortalLifecycle.xml
epp/docs/branches/5.2/Reference_Guide/en-US/modules/WSRP.xml
epp/docs/branches/5.2/Reference_Guide/en-US/modules/eXoJCR/ws/framework-for-cross-domain-ajax.xml
Log:
Further QE-related edits.
Modified: epp/docs/branches/5.2/Reference_Guide/en-US/Book_Info.xml
===================================================================
--- epp/docs/branches/5.2/Reference_Guide/en-US/Book_Info.xml 2011-12-08 10:36:22 UTC (rev
8217)
+++ epp/docs/branches/5.2/Reference_Guide/en-US/Book_Info.xml 2011-12-08 21:51:37 UTC (rev
8218)
@@ -9,7 +9,7 @@
<productname>JBoss Enterprise Portal Platform</productname>
<productnumber>5.2</productnumber>
<edition>5.2.0</edition>
- <pubsnumber>17</pubsnumber>
+ <pubsnumber>18</pubsnumber>
<abstract>
<para>
This Reference Guide is a high-level usage document. It deals with more
advanced topics than the Installation and User Guides, adding new content or taking
concepts discussed in the earlier documents further. It aims to provide supporting
documentation for advanced users of the JBoss Enterprise Portal Platform product. Its
primary focus is on advanced use of the product and it assumes an intermediate or advanced
knowledge of the technology and terms.
Modified: epp/docs/branches/5.2/Reference_Guide/en-US/Revision_History.xml
===================================================================
--- epp/docs/branches/5.2/Reference_Guide/en-US/Revision_History.xml 2011-12-08 10:36:22
UTC (rev 8217)
+++ epp/docs/branches/5.2/Reference_Guide/en-US/Revision_History.xml 2011-12-08 21:51:37
UTC (rev 8218)
@@ -8,6 +8,20 @@
<simpara>
<revhistory>
<revision>
+ <revnumber>5.2.0-18</revnumber>
+ <date>Fri Dec 9 2011</date>
+ <author>
+ <firstname>Scott</firstname>
+ <surname>Mumford</surname>
+ <email></email>
+ </author>
+ <revdescription>
+ <simplelist>
+ <member>Further QE-related edits.</member>
+ </simplelist>
+ </revdescription>
+ </revision>
+ <revision>
<revnumber>5.2.0-17</revnumber>
<date>Thu Dec 8 2011</date>
<author>
Modified:
epp/docs/branches/5.2/Reference_Guide/en-US/extras/Advanced_Development_JCR_lock-manager-config/you.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide/en-US/extras/Advanced_Development_JCR_lock-manager-config/you.xml 2011-12-08
10:36:22 UTC (rev 8217)
+++
epp/docs/branches/5.2/Reference_Guide/en-US/extras/Advanced_Development_JCR_lock-manager-config/you.xml 2011-12-08
21:51:37 UTC (rev 8218)
@@ -19,7 +19,7 @@
For another cache-loader class you should use another template with
cache-loader specific parameters
-->
- <loader class="org.jboss.cache.loader.JDBCCacheLoader"
async=q"false" fetchPersistentState="false"
+ <loader class="org.jboss.cache.loader.JDBCCacheLoader"
async="false" fetchPersistentState="false"
ignoreModifications="false" purgeOnStartup="false">
<properties>
cache.jdbc.table.name=${jbosscache-cl-cache.jdbc.table.name}
Modified:
epp/docs/branches/5.2/Reference_Guide/en-US/extras/PortalDevelopment_PortalLifecycle/default160.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide/en-US/extras/PortalDevelopment_PortalLifecycle/default160.xml 2011-12-08
10:36:22 UTC (rev 8217)
+++
epp/docs/branches/5.2/Reference_Guide/en-US/extras/PortalDevelopment_PortalLifecycle/default160.xml 2011-12-08
21:51:37 UTC (rev 8218)
@@ -1,6 +1,6 @@
<servlet>
<servlet-name>GateInServlet</servlet-name>
- <servlet-class>org.gatein.wci.command.CommandServlet</servlet-class>
+ <servlet-class>org.gatein.wci.api.GateInServlet</servlet-class>
<load-on-startup>0</load-on-startup>
</servlet>
Modified:
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/PortalLifecycle.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/PortalLifecycle.xml 2011-12-08
10:36:22 UTC (rev 8217)
+++
epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/PortalLifecycle.xml 2011-12-08
21:51:37 UTC (rev 8218)
@@ -3,50 +3,60 @@
<!ENTITY % BOOK_ENTITIES SYSTEM "Reference_Guide.ent">
%BOOK_ENTITIES;
]>
-<chapter id="chap-Reference_Guide-Portal_Life_cycle">
- <title>Portal Life-cycle</title>
- <section id="sect-Reference_Guide-Portal_Life_cycle-Overview">
- <title>Overview</title>
+ <chapter id="chap-Reference_Guide-Portal_Life_cycle">
+ <title>Portal Life-cycle</title>
+
+ <section id="sect-Reference_Guide-Portal_Life_cycle-Overview">
+ <title>Overview</title>
+
<para>
This chapter describes the portal life-cycle from the application server
start to its stop including how requests are handled.
- </para>
-
- </section>
-
- <section
id="sect-Reference_Guide-Portal_Life_cycle-Application_Server_start_and_stop">
- <title>Application Server start and stop</title>
+ </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Portal_Life_cycle-Application_Server_start_and_stop">
+ <title>Application Server start and stop</title>
+
<para>
A portal instance is simply a set of web applications deployed as
<filename>EAR</filename> and <filename>WAR</filename> archives.
Portlets are also part of an enhanced WAR called a portlet application.
- </para>
+ </para>
+
<para>
JBoss Enterprise Portal Platform does not require any particular setup for
your portlet in most common scenarios and the <filename>web.xml</filename>
file can remain without any JBoss Enterprise Portal Platform specific configuration.
- </para>
+ </para>
+
<para>
During deployment, JBoss Enterprise Portal Platform will automatically and
transparently inject a servlet into the portlet application to be able to interact with
it. This feature is dependent on the underlying servlet container but will work out of the
box on the proposed bundles.
- </para>
-
- </section>
-
- <!--
+ </para>
+ </section>
+<!--
TODO: Define the added listener
- --><!--
+ -->
+<!--
<section id="sect-Reference_Guide-Portal_Lifecycle-The_Listener">
<title>The Listener</title>
<para>
In the web.xml we can find servlet listener:
-</para> --><!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default158.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting> <!-
================================================================== ->
+</para> -->
+<!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default158.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
-->
+<!-- <programlisting> <!-
================================================================== ->
<!- LISTENER ->
<!- ================================================================== ->
<listener>
<listener-class>org.exoplatform.portal.application.PortalSessionListener</listener-class>
</listener>
-</programlisting> --><!-- <para>
+</programlisting> -->
+<!-- <para>
That listener implements the HttpSessionListener which means it is called each time a
session is created or destroyed; in other words, a session is created each time a user
send a first request to the portal. That session is destroyed when he has not sent request
to the portal for a long time or when he closes his browser.
</para>
-<programlisting language="Java" role="Java"><xi:include
parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/PortalSessionListener.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting>public class PortalSessionListener implements
HttpSessionListener
-</programlisting> --><!-- <para>
+<programlisting language="Java" role="Java"><xi:include
parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/PortalSessionListener.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
-->
+<!-- <programlisting>public class PortalSessionListener implements
HttpSessionListener
+</programlisting> -->
+<!-- <para>
Only the destroy method of the Listener object is implemented and it is used to flush
resources when a user portal session expires. Here is the code:
-</para> --><!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default159.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting> /**
+</para> -->
+<!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default159.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
-->
+<!-- <programlisting> /**
* This method is called when a HTTP session of a Portal instance is destroyed.
* By default the session time is 30 minutes.
*
@@ -81,103 +91,60 @@
}
}
</programlisting>
- --> <section
id="sect-Reference_Guide-Portal_Life_cycle-The_Command_Servlet">
- <title>The Command Servlet</title>
+ -->
+ <section
id="sect-Reference_Guide-Portal_Life_cycle-The_Command_Servlet">
+ <title>The Command Servlet</title>
+
<para>
The CommandServlet is called by the portlet container for requests to
particular portlets, it also includes some <literal>init</literal> code when
the portal is launched. This servlet
(<literal>org.gatein.wci.api.GateInServlet</literal>) is automatically added
during the deployment of each portlet application and mapped to
<literal>/gateinservlet</literal>.
- </para>
+ </para>
+
<para>
This is equivalent to adding the following into
<filename>web.xml</filename>.
- </para>
+ </para>
+
<note>
<title>Servlet Configuration</title>
- <para>
- <emphasis role="bold">As the servlet is already
configured this example is for information only.</emphasis>
+
+ <para>
+ <emphasis role="bold">As the servlet is already configured
this example is for information only.</emphasis>
</para>
-
- </note>
-
+ </note>
<programlisting language="XML" role="XML"><xi:include
href="../../extras/PortalDevelopment_PortalLifecycle/default160.xml"
parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"
/></programlisting>
- <!-- <programlisting language="XML"
role="XML"><![CDATA[<servlet>
-<servlet-name>GateInServlet</servlet-name>
-<servlet-class>org.gatein.wci.command.CommandServlet</servlet-class>
-<load-on-startup>0</load-on-startup>
-</servlet>
-<servlet-mapping>
-<servlet-name>GateInServlet</servlet-name>
-<url-pattern>/gateinservlet</url-pattern>
-</servlet-mapping>]]></programlisting> --> <para>
+ <para>
It is possible to filter on the <literal>GateInServlet</literal>
by filtering the URL pattern used by the servlet mapping.
- </para>
+ </para>
+
<para>
The example below would create a servlet filter that calculates the time of
execution of a portlet request.
- </para>
+ </para>
+
<para>
The filter class:
- </para>
-
+ </para>
<programlisting language="Java" role="Java"><xi:include
href="../../extras/PortalDevelopment_PortalLifecycle/MyFilter.java"
parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"
/></programlisting>
- <!-- <programlisting language="Java"
role="JAVA"><![CDATA[package org.example;
-import java.io.IOException;
-import javax.servlet.FilterChain;
-import javax.servlet.FilterConfig;
-import javax.servlet.ServletException;
-import javax.servlet.ServletRequest;
-import javax.servlet.ServletResponse;
-public class MyFilter implements javax.servlet.Filter {
-public void doFilter(ServletRequest request, ServletResponse response,
-FilterChain chain) throws IOException, ServletException
-{
-long beforeTime = System.currentTimeMillis();
-chain.doFilter(request, response);
-long afterTime = System.currentTimeMillis();
-System.out.println("Time to execute the portlet request (in ms): " + (afterTime
- beforeTime));
-}
-public void init(FilterConfig config) throws ServletException
-{
-}
-public void destroy()
-{
-}
-}
-]]></programlisting> --> <para>
+ <para>
The Java EE web application configuration file
(<filename>web.xml</filename>) of the portlet is the file on which we want to
know the time to serve a portlet request.
- </para>
+ </para>
+
<para>
As mentioned above nothing specific to JBoss Enterprise Portal Platform needs
to be included, only the URL pattern to set has to be known.
- </para>
-
+ </para>
<programlisting language="XML" role="XML"><xi:include
href="../../extras/PortalDevelopment_PortalLifecycle/default161.xml"
parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"
/></programlisting>
- <!-- <programlisting language="XML"
role="XML"><![CDATA[<?xml version="1.0"?>
-<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
-version="2.5">
-<filter>
-<filter-name>MyFilter</filter-name>
-<filter-class>org.example.MyFilter</filter-class>
-</filter>
-<filter-mapping>
-<filter-name>MyFilter</filter-name>
-<url-pattern>/gateinservlet</url-pattern>
-<dispatcher>INCLUDE</dispatcher>
-</filter-mapping>
-</web-app>]]></programlisting> --> <para>
- <note>
- <title>INCLUDE dispatcher</title>
- <para>
- It is important to set <literal>INCLUDE</literal> as
dispatcher as the portal will always hit the <literal>GateInServlet</literal>
through a request dispatcher. Without this, the filter will not be triggered, unless
direct access to a resource (such as an image) is set.
- </para>
-
- </note>
-
- </para>
-
- </section>
-
- <!--
-<para>
-Here is its definition in the web.xml file:
-</para> --><!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default162.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting>
+ <note>
+ <title>INCLUDE dispatcher</title>
+
+ <para>
+ It is important to set <literal>INCLUDE</literal> as
dispatcher as the portal will always hit the <literal>GateInServlet</literal>
through a request dispatcher. Without this, the filter will not be triggered, unless
direct access to a resource (such as an image) is set.
+ </para>
+ </note>
+ </section>
+<!--
+ <para>
+ Here is its definition in the web.xml file:
+ </para>
+<programlisting language="Java" role="Java"><xi:include
parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default162.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+<programlisting>
<servlet>
<servlet-name>portal</servlet-name>
<servlet-class>org.exoplatform.portal.application.PortalController</servlet-class>
@@ -187,9 +154,12 @@
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
-</programlisting> --><!-- <para>
-The load-on-startup tag tells that the init method of the servlet is called when the
application server starts. We also define some configuration for the portal at the path
WEB-INF/webui-configuration.xml inside the portal WAR.
-</para> --><!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/is1.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting>/**
+</programlisting>
+ <para>
+ The load-on-startup tag tells that the init method of the servlet is called when
the application server starts. We also define some configuration for the portal at the
path WEB-INF/webui-configuration.xml inside the portal WAR.
+ </para>
+<programlisting language="Java" role="Java"><xi:include
parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/is1.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+<programlisting>/**
* The PortalContainer servlet is the main entry point for the GateIn Portal product.
*
* Both the init() and service() methods are implemented. The first one is used to
configure all the
@@ -239,11 +209,16 @@
log.info("Init of PortalController Servlet successful");
}
...
-</programlisting> --><!-- <para>
-We see that a PortalApplication class is instantiated, initialized and then referenced
inside the WebAppController. Note that the WebAppController is a component located inside
GateIn IoC service container (and hence registered in one of our service configuration XML
file).
-</para> --><!-- <para>
-The
<code><strong>PortalApplication</strong></code>
extends the
<code><strong>WebuiApplication</strong></code>
which itself extends the
<code><strong>Application</strong></code>
abstract class.
-</para> --><!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/PortalApplication.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting>public class PortalApplication extends
WebuiApplication {
+</programlisting>
+ <para>
+ We see that a PortalApplication class is instantiated, initialized and then
referenced inside the WebAppController. Note that the WebAppController is a component
located inside GateIn IoC service container (and hence registered in one of our service
configuration XML file).
+ </para>
+
+ <para>
+ The
<code><strong>PortalApplication</strong></code>
extends the
<code><strong>WebuiApplication</strong></code>
which itself extends the
<code><strong>Application</strong></code>
abstract class.
+ </para>
+<programlisting language="Java" role="Java"><xi:include
parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/PortalApplication.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+<programlisting>public class PortalApplication extends WebuiApplication {
protected static Log log = ExoLogger.getLogger("portal:PortalApplication");
final static public String PORTAL_APPLICATION_ID = "PortalApplication" ;
private ServletConfig sconfig_ ;
@@ -267,12 +242,16 @@
setResourceResolver(resolver) ;
}
...
-</programlisting> --><!-- <para>
-The main goal of this constructor is to fill an
<code><strong>ApplicationResourceResolver</strong></code>
with several
<code><strong>ResourceResolver</strong></code>
object that will allow the application to check for files such as groovy templates into
different locations. Here the goal of the
<code><strong>ResourceResolver</strong></code>
is to abstract the different mechanisms to extract files from different location. In the
previous code sample the
<code><strong>ServletResourceResolver</strong></code>
is used and hence methods based on the servlet context object are defined. Note that the
<code><strong>ApplicationResourceResolver</strong></code>
is also a class of type
<code><strong>ResourceResolver</strong></code>
but a special one as it can also contains several
<code><strong>ResourceResolver</strong></cod!
e> itself.
-</para>
-<para>
-Then the
<code><strong>onInit()</strong></code>
method of the
<code><strong>PortalApplication</strong></code>
is called.
-</para> --><!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default163.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting>/**
+</programlisting>
+ <para>
+ The main goal of this constructor is to fill an
<code><strong>ApplicationResourceResolver</strong></code>
with several
<code><strong>ResourceResolver</strong></code>
object that will allow the application to check for files such as groovy templates into
different locations. Here the goal of the
<code><strong>ResourceResolver</strong></code>
is to abstract the different mechanisms to extract files from different location. In the
previous code sample the
<code><strong>ServletResourceResolver</strong></code>
is used and hence methods based on the servlet context object are defined. Note that the
<code><strong>ApplicationResourceResolver</strong></code>
is also a class of type
<code><strong>ResourceResolver</strong></code>
but a special one as it can also contains several
<code><strong>ResourceResolver</strong>!
;</code> itself.
+ </para>
+
+ <para>
+ Then the
<code><strong>onInit()</strong></code>
method of the
<code><strong>PortalApplication</strong></code>
is called.
+ </para>
+<programlisting language="Java" role="Java"><xi:include
parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default163.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+<programlisting>/**
* This method first calls the super.onInit() of the WebuiApplication. That super method
parse the XML
* file and stores its content in the ConfigurationManager object. It also set up he
StateManager and
* init the application life-cycle phases.
@@ -288,12 +267,16 @@
applicationResourceBundleNames_[i] = applicationResourceBundleNames_[i].trim() ;
}
}
-</programlisting> --><!-- <para>
-The
<code><strong>ConfigurationManager</strong></code>
object parses the XML configuration file. The idea of the framework, once again, is to
abstract the type of
<code><strong>webapplication</strong></code>
in used. Hence the
<code><strong>webui-configuration.xml</strong></code>
file is used by both the portal and portlet applications.
-</para>
-<para>
-Here is the
<code><strong>webui-configuration</strong></code>:
-</para> --><!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default164.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting><webui-configuration>
+</programlisting>
+ <para>
+ The
<code><strong>ConfigurationManager</strong></code>
object parses the XML configuration file. The idea of the framework, once again, is to
abstract the type of
<code><strong>webapplication</strong></code>
in used. Hence the
<code><strong>webui-configuration.xml</strong></code>
file is used by both the portal and portlet applications.
+ </para>
+
+ <para>
+ Here is the
<code><strong>webui-configuration</strong></code>:
+ </para>
+<programlisting language="Java" role="Java"><xi:include
parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default164.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+<programlisting><webui-configuration>
<application>
<init-params>
<param>
@@ -320,38 +303,48 @@
</events>
</application>
</webui-configuration>
-</programlisting> --><!-- <para>
-In the previous XML file we see that we define several tags such as:
-</para>
-<para>
-1.1.1 The ui-component-root
-</para>
-<para>
-Here it is the class
<code><strong>org.exoplatform.portal.webui.workspace.UIPortalApplication</strong></code>
which is a class that extends the
<code><strong>UIApplication</strong></code>
and hence is a sibling of
<code><strong>UIPortletApplication</strong></code>
(used by any GateIn Portlets as the Parent class to build the portlet component tree).
-</para>
-<para>
-The
<code><strong>UIPortalApplication</strong></code>
is responsible for building its subtrees - at request time according to some configuration
parameters. If all components are displayed it is composed of 3 UI components:
-</para>
-<itemizedlist>
-<listitem>
-<para>
-<code><strong>UIControlWorkSpace</strong></code>
: the left expandable column that can contains gadget containers and the start menu
-</para>
-</listitem>
-<listitem>
-<para>
-<code><strong>UIWorkingWorkSpace</strong></code>:
the right part that can display the normal or webos portal layouts.
-</para>
-</listitem>
-<listitem>
-<para>
-<code><strong>UIPopupWindow</strong></code>:
a popup window that display or not.
-</para>
-</listitem>
-</itemizedlist>
-<para>
-The
<code><strong>UIPortalApplication</strong><code>
constructor is shown next and is the starting point to build the UI Component tree to
which Pages and Portlets will also be mounted. We will not describe that behavior here.
-</para> --><!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/is2.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting>/**
+</programlisting>
+ <para>
+ In the previous XML file we see that we define several tags such as:
+ </para>
+
+ <para>
+ 1.1.1 The ui-component-root
+ </para>
+
+ <para>
+ Here it is the class
<code><strong>org.exoplatform.portal.webui.workspace.UIPortalApplication</strong></code>
which is a class that extends the
<code><strong>UIApplication</strong></code>
and hence is a sibling of
<code><strong>UIPortletApplication</strong></code>
(used by any GateIn Portlets as the Parent class to build the portlet component tree).
+ </para>
+
+ <para>
+ The
<code><strong>UIPortalApplication</strong></code>
is responsible for building its subtrees - at request time according to some configuration
parameters. If all components are displayed it is composed of 3 UI components:
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+
<code><strong>UIControlWorkSpace</strong></code>
: the left expandable column that can contains gadget containers and the start menu
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+
<code><strong>UIWorkingWorkSpace</strong></code>:
the right part that can display the normal or webos portal layouts.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+
<code><strong>UIPopupWindow</strong></code>:
a popup window that display or not.
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ The
<code><strong>UIPortalApplication</strong><code>
constructor is shown next and is the starting point to build the UI Component tree to
which Pages and Portlets will also be mounted. We will not describe that behavior here.
+ </para>
+<programlisting language="Java" role="Java"><xi:include
parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/is2.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+<programlisting>/**
* The constructor of this class is used to build the tree of UI components that will be
aggregated
* in the portal page.
*
@@ -405,42 +398,57 @@
setOwner(context.getPortalOwner());
}
...
-</programlisting> --><!-- <para>
-1.1.1 The StateManager
-</para>
-<para>
-The
<code><strong>StateManager</strong></code>
here is in the
<code><strong>org.exoplatform.portal.application</strong></code>
package which is an abstract class.
-</para> --><!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/StateManager.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting>abstract public class StateManager {
+</programlisting>
+ <para>
+ 1.1.1 The StateManager
+ </para>
+
+ <para>
+ The
<code><strong>StateManager</strong></code>
here is in the
<code><strong>org.exoplatform.portal.application</strong></code>
package which is an abstract class.
+ </para>
+<programlisting language="Java" role="Java"><xi:include
parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/StateManager.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+<programlisting>abstract public class StateManager {
abstract public UIApplication restoreUIRootComponent(WebuiRequestContext context) throws
Exception ;
abstract public void storeUIRootComponent(WebuiRequestContext context) throws Exception
;
abstract public void expire(String sessionId, WebuiApplication app) throws Exception ;
}
-</programlisting> --><!-- <para>
-The goal of the
<code><strong>StateManager</strong></code>
is to abstract the way
<code><strong>UIApplication</strong></code>
are stored and restored for all the user session lifetime. The expire method is called
from the listener we have introduced before in this chapter.
-</para>
-<para>
-1.1.1 The application-life-cycle-listeners
-</para>
-<para>
-There are 2 life-cycle listeners in the Portal, one for the real business logic
(<code><strong>PortalApplicationLifecycle</strong></code>),
the other one for some monitoring issues. They both implement the interface
<code><strong>ApplicationLifecycle<E extends
RequestContext></strong></code>.
-</para> --><!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default165.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting>public interface ApplicationLifecycle<E
extends RequestContext> {
+</programlisting>
+ <para>
+ The goal of the
<code><strong>StateManager</strong></code>
is to abstract the way
<code><strong>UIApplication</strong></code>
are stored and restored for all the user session lifetime. The expire method is called
from the listener we have introduced before in this chapter.
+ </para>
+
+ <para>
+ 1.1.1 The application-life-cycle-listeners
+ </para>
+
+ <para>
+ There are 2 life-cycle listeners in the Portal, one for the real business logic
(<code><strong>PortalApplicationLifecycle</strong></code>),
the other one for some monitoring issues. They both implement the interface
<code><strong>ApplicationLifecycle<E extends
RequestContext></strong></code>.
+ </para>
+<programlisting language="Java" role="Java"><xi:include
parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default165.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+<programlisting>public interface ApplicationLifecycle<E extends
RequestContext> {
public void onInit(Application app) throws Exception ;
public void onStartRequest(Application app, E context) throws Exception ;
public void onEndRequest(Application app, E context) throws Exception ;
public void onDestroy(Application app) throws Exception ;
}
-</programlisting> --><!-- <para>
-Each registered life-cycle listener will then be able to get events when several states
of the portal life-cycle are reached.
-</para>
-<para>
-1.1 The Request Handler
-</para>
-<para>
-Once started and fully configured, the portal application WAR can handle HTTP requests.
-</para>
-<para>
-The entry point is for sure the PortalController servlet we have already seen in the
current chapter and defined in the
<code><strong>web.xml</strong></code>
of the portal context.
-</para> --><!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default166.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting>...
+</programlisting>
+ <para>
+ Each registered life-cycle listener will then be able to get events when several
states of the portal life-cycle are reached.
+ </para>
+
+ <para>
+ 1.1 The Request Handler
+ </para>
+
+ <para>
+ Once started and fully configured, the portal application WAR can handle HTTP
requests.
+ </para>
+
+ <para>
+ The entry point is for sure the PortalController servlet we have already seen in
the current chapter and defined in the
<code><strong>web.xml</strong></code>
of the portal context.
+ </para>
+<programlisting language="Java" role="Java"><xi:include
parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default166.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+<programlisting>...
/**
* This method simply delegates the incoming call to the WebAppController stored in the
Portal Container object
*/
@@ -464,9 +472,12 @@
}
}
...
-</programlisting> --><!-- <para>
-The
<code><strong>WebAppController</strong></code>
is also a simple class on which several handlers can be bound. We have already seen that
the
<code><strong>PortalRequestHandler</strong></code>
was already added in the init method of the servlet.
-</para> --><!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default167.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting>...
+</programlisting>
+ <para>
+ The
<code><strong>WebAppController</strong></code>
is also a simple class on which several handlers can be bound. We have already seen that
the
<code><strong>PortalRequestHandler</strong></code>
was already added in the init method of the servlet.
+ </para>
+<programlisting language="Java" role="Java"><xi:include
parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default167.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+<programlisting>...
/**
* The WebAppControler along with the PortalRequestHandler defined in the init() method of
the
* PortalController servlet (controller.register(new PortalRequestHandler())) also add
the
@@ -481,9 +492,12 @@
register(new CommandHandler()) ;
}
...
-</programlisting> --><!-- <para>
-Then the service method - modelled according to the servlet specification is called:
-</para> --><!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default168.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting>...
+</programlisting>
+ <para>
+ Then the service method - modelled according to the servlet specification is
called:
+ </para>
+<programlisting language="Java" role="Java"><xi:include
parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default168.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+<programlisting>...
/**
* This is the first method - in the GateIn web framework - reached by incoming HTTP
request, it acts like a
* servlet service() method
@@ -523,9 +537,12 @@
}
}
...
-</programlisting> --><!-- <para>
-The handler in the portal case is the
<code><strong>PortalRequestHandler</strong></code>
which extends
<code><strong>WebRequestHandler</strong></code>
and that implement the abstract methods, mainly the execute() one.
-</para> --><!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/that.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting>/**
+</programlisting>
+ <para>
+ The handler in the portal case is the
<code><strong>PortalRequestHandler</strong></code>
which extends
<code><strong>WebRequestHandler</strong></code>
and that implement the abstract methods, mainly the execute() one.
+ </para>
+<programlisting language="Java" role="Java"><xi:include
parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/that.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+<programlisting>/**
* Created by The GateIn Platform SAS
* Mar 21, 2007
*
@@ -544,9 +561,12 @@
public void onDestroy(WebAppController controler) throws Exception {
}
}
-</programlisting> --><!-- <para>
-Here is the main class and the entire algorithm is described in the javadoc:
-</para> --><!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/handle.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting>/**
+</programlisting>
+ <para>
+ Here is the main class and the entire algorithm is described in the javadoc:
+ </para>
+<programlisting language="Java" role="Java"><xi:include
parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/handle.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+<programlisting>/**
* Created by The GateIn Platform SAS
* Dec 9, 2006
*
@@ -609,12 +629,16 @@
WebuiRequestContext.setCurrentInstance(null) ;
}
}
-</programlisting> --><!-- <para>
-The PortalRequestContext class is an important one as it is used in many places. The
PortalRequestContext class wraps most of the request information. Accessing it from
everywhere is quite simple as the object is stored in a ThreadLocal one, which means it
bound to the current request thread. Hence a single call to
WebuiRequestContext.getCurrentContext() will return the correct PortalRequestContext.
-</para>
-<para>
-As you can see, the PortalRequestContext extends the WebuiRequestContext one which also
extends the abstract class RequestContext. Once again this hierarchy is to abstract the
type of context in use , would it be a portal or portlet one.
-</para> --><!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/is3.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting>/**
+</programlisting>
+ <para>
+ The PortalRequestContext class is an important one as it is used in many places.
The PortalRequestContext class wraps most of the request information. Accessing it from
everywhere is quite simple as the object is stored in a ThreadLocal one, which means it
bound to the current request thread. Hence a single call to
WebuiRequestContext.getCurrentContext() will return the correct PortalRequestContext.
+ </para>
+
+ <para>
+ As you can see, the PortalRequestContext extends the WebuiRequestContext one
which also extends the abstract class RequestContext. Once again this hierarchy is to
abstract the type of context in use , would it be a portal or portlet one.
+ </para>
+<programlisting language="Java" role="Java"><xi:include
parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/is3.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+<programlisting>/**
* Created by The GateIn Platform SAS
* May 7, 2006
*
@@ -670,9 +694,12 @@
public static <T extends RequestContext> T getCurrentInstance() { return
(T)tlocal_.get() ; }
public static void setCurrentInstance(RequestContext ctx) { tlocal_.set(ctx) ; }
}
-</programlisting> --><!-- <para>
-The WebuiRequestContext abstract class extends the RequestContext one and adds method for
a Web environment such as accesses to the request and response objects or a list of
components to update when using an Ajax call. More in the following header of the class:
-</para> --><!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/to.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting>/**
+</programlisting>
+ <para>
+ The WebuiRequestContext abstract class extends the RequestContext one and adds
method for a Web environment such as accesses to the request and response objects or a
list of components to update when using an Ajax call. More in the following header of the
class:
+ </para>
+<programlisting language="Java" role="Java"><xi:include
parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/to.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+<programlisting>/**
* Created by The GateIn Platform SAS
* May 7, 2006
*
@@ -740,12 +767,16 @@
public StateManager getStateManager() { return stateManager_; }
public void setStateManager(StateManager manager) { stateManager_ = manager ; }
}
-</programlisting> --><!-- <para>
-The PortalRequestContext mainly implements the abstract method already shown and only add
few ones such as a reference to the portal owner or some information on the current
navigation node path and the state of the portal (PUBLIC or PRIVATE ones)
-</para>
-<para>
-The PortalRequestHandler then tries to restore the UI component tree by calling the
method restoreUIRootComponent(). The first time, there is nothing to restore and in that
case the following part of code in the method is used:
-</para> --><!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/type.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting> if(state == null) {
+</programlisting>
+ <para>
+ The PortalRequestContext mainly implements the abstract method already shown and
only add few ones such as a reference to the portal owner or some information on the
current navigation node path and the state of the portal (PUBLIC or PRIVATE ones)
+ </para>
+
+ <para>
+ The PortalRequestHandler then tries to restore the UI component tree by calling
the method restoreUIRootComponent(). The first time, there is nothing to restore and in
that case the following part of code in the method is used:
+ </para>
+<programlisting language="Java" role="Java"><xi:include
parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/type.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+<programlisting> if(state == null) {
synchronized(uiApplications) {
ConfigurationManager cmanager = app.getConfigurationManager() ;
String uirootClass = cmanager.getApplication().getUIRootComponent() ;
@@ -766,9 +797,12 @@
pcontainer.createSessionContainer(context.getSessionId(), uiApplication.getOwner()) ;
}
}
-</programlisting> --><!-- <para>
-The configuration manager object bound to the PortalApplication one is used to get the
type for the root component which is then instanciated. the UserPortalConfig object -
which is wrapper around the portal information for a given user - is also used and stored
as an attribute in the PortalRequestContext. The UIPortalApplication is then created using
the method createUIComponent() that is responsible of instanciating the component but also
to configure it.
-</para> --><!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default169.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting> public <T extends UIComponent>
T createUIComponent(Class<T> type, String configId, String id,
WebuiRequestContext context) throws Exception{
+</programlisting>
+ <para>
+ The configuration manager object bound to the PortalApplication one is used to
get the type for the root component which is then instanciated. the UserPortalConfig
object - which is wrapper around the portal information for a given user - is also used
and stored as an attribute in the PortalRequestContext. The UIPortalApplication is then
created using the method createUIComponent() that is responsible of instanciating the
component but also to configure it.
+ </para>
+<programlisting language="Java" role="Java"><xi:include
parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default169.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+<programlisting> public <T extends UIComponent> T
createUIComponent(Class<T> type, String configId, String id,
WebuiRequestContext context) throws Exception{
Component config = configManager_.getComponentConfig(type, configId) ;
if(config == null) {
throw new Exception("Cannot find the configuration for the component " +
type.getName() + ", configId " +configId) ;
@@ -778,9 +812,12 @@
config.getUIComponentLifecycle().init(uicomponent, context) ;
return type.cast(uicomponent) ;
}
-</programlisting> --><!-- <para>
-The ConfigurationManager method getComponentConfig() returns the Component object filled,
it is a wrapper that contains all the information on the parameters for the class.
Annotations are used to configure the instance as shown here:
-</para> --><!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default170.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting>@ComponentConfigs({
+</programlisting>
+ <para>
+ The ConfigurationManager method getComponentConfig() returns the Component
object filled, it is a wrapper that contains all the information on the parameters for the
class. Annotations are used to configure the instance as shown here:
+ </para>
+<programlisting language="Java" role="Java"><xi:include
parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default170.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+<programlisting>@ComponentConfigs({
@ComponentConfig (
life-cycle = UIPortalApplicationLifecycle.class,
template = "system:/groovy/portal/webui/workspace/UIPortalApplication.gtmpl",
@@ -793,32 +830,40 @@
initParams = @ParamConfig( name = "public.showControlWorkspace", value =
"false" )
)
})
-</programlisting> --><!-- <para>
-The processDecode() method of the UIPortalApplication is doing 3 actions:
-</para>
-<itemizedlist>
-<listitem>
-<para>
-if the nodePath is null (case of the first request) a call to
super.processDecode(context) is made and we end the method here
-</para>
-</listitem>
-<listitem>
-<para>
-if the nodePath exist but is equals to the current one then we also call super and stops
here
-</para>
-</listitem>
-<listitem>
-<para>
-if the requested nodePath is not equals to the current one , then an event of type
PageNodeEvent.CHANGE<emphasis>PAGE</emphasis>NODE is sent to the asociated
EventListener; a call to super is then done
-</para>
-</listitem>
-</itemizedlist>
-<para>
-The first case it simply does nothing. Note that the super.processDecode() goes up to the
UIComponent which also calls the processDecode() method on the Lifecycle object that can
be associated with the UIComponent
-</para>
-<para>
-The processAction() method of the UIPortalApplication is then called, as there is no
method in the object itself it will call the processAction() of the
UIPortalApplicationLifecycle bound to the UI component:
-</para> --><!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default171.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting> public void processAction(UIComponent
uicomponent, WebuiRequestContext context) throws Exception {
+</programlisting>
+ <para>
+ The processDecode() method of the UIPortalApplication is doing 3 actions:
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ if the nodePath is null (case of the first request) a call to
super.processDecode(context) is made and we end the method here
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ if the nodePath exist but is equals to the current one then we also call
super and stops here
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ if the requested nodePath is not equals to the current one , then an event
of type PageNodeEvent.CHANGE<emphasis>PAGE</emphasis>NODE is sent to the
asociated EventListener; a call to super is then done
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ The first case it simply does nothing. Note that the super.processDecode() goes
up to the UIComponent which also calls the processDecode() method on the Lifecycle object
that can be associated with the UIComponent
+ </para>
+
+ <para>
+ The processAction() method of the UIPortalApplication is then called, as there
is no method in the object itself it will call the processAction() of the
UIPortalApplicationLifecycle bound to the UI component:
+ </para>
+<programlisting language="Java" role="Java"><xi:include
parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/default171.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+<programlisting> public void processAction(UIComponent uicomponent,
WebuiRequestContext context) throws Exception {
UIPortalApplication uiApp = (UIPortalApplication) uicomponent ;
String componentId =
context.getRequestParameter(context.getUIComponentIdParameterName()) ;
if(componentId == null) return;
@@ -827,12 +872,16 @@
if(uiTarget == uicomponent) super.processAction(uicomponent, context) ;
uiTarget.processAction(context) ;
}
-</programlisting> --><!-- <para>
-If no uicomponent object is targeted, which is the case the first time (unless a
bookmarked link is used) then nothing is done. Otherwise, the targeted component is
extracted and a call of its processAction() method is executed.
-</para>
-<para>
-Then it is time to render the content and this is done inside the processRender() method.
The method of the UIPortalApplication is shown here and it is the one that handles either
full portal generation or AJAX request:
-</para> --><!-- <programlisting language="Java"
role="Java"><xi:include parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/it.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
--><!-- <programlisting> /**
+</programlisting>
+ <para>
+ If no uicomponent object is targeted, which is the case the first time (unless a
bookmarked link is used) then nothing is done. Otherwise, the targeted component is
extracted and a call of its processAction() method is executed.
+ </para>
+
+ <para>
+ Then it is time to render the content and this is done inside the
processRender() method. The method of the UIPortalApplication is shown here and it is the
one that handles either full portal generation or AJAX request:
+ </para>
+<programlisting language="Java" role="Java"><xi:include
parse="text"
href="../../extras/PortalDevelopment_PortalLifecycle/it.java"
xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
+<programlisting> /**
* The processrender() method handles the creation of the returned HTML either for a full
* page render or in the case of an AJAX call
*
@@ -893,8 +942,6 @@
w.write("</div>") ;
}
}
-</programlisting> --><!-- </section>
-
- -->
-</chapter>
-
+</programlisting>
+-->
+ </chapter>
Modified: epp/docs/branches/5.2/Reference_Guide/en-US/modules/WSRP.xml
===================================================================
--- epp/docs/branches/5.2/Reference_Guide/en-US/modules/WSRP.xml 2011-12-08 10:36:22 UTC
(rev 8217)
+++ epp/docs/branches/5.2/Reference_Guide/en-US/modules/WSRP.xml 2011-12-08 21:51:37 UTC
(rev 8218)
@@ -156,7 +156,7 @@
<para>
If you are not going to use WSRP in JBoss Enterprise Portal Platform, it will
not adversely affect your installation to leave it
- as-is. Otherwise, you can just remove the
+ as is. Otherwise, you can just remove the
<filename>gatein-wsrp-integration.ear</filename>
file from your AS deploy directory.
</para>
Modified:
epp/docs/branches/5.2/Reference_Guide/en-US/modules/eXoJCR/ws/framework-for-cross-domain-ajax.xml
===================================================================
---
epp/docs/branches/5.2/Reference_Guide/en-US/modules/eXoJCR/ws/framework-for-cross-domain-ajax.xml 2011-12-08
10:36:22 UTC (rev 8217)
+++
epp/docs/branches/5.2/Reference_Guide/en-US/modules/eXoJCR/ws/framework-for-cross-domain-ajax.xml 2011-12-08
21:51:37 UTC (rev 8218)
@@ -4,93 +4,93 @@
%BOOK_ENTITIES;
]>
<chapter id="chap-Reference_Guide-Framework_for_cross_domain_AJAX">
- <title>Framework for cross-domain AJAX</title>
- <para>
- (<ulink
url="https://anonsvn.jboss.org/repos/exo-jcr/ws/trunk/exo.ws.framewo...>)
- </para>
- <section
id="sect-Reference_Guide-Framework_for_cross_domain_AJAX-Motivation">
- <title>Motivation</title>
- <para>
- XmlHttpRequest objects are bound by the same origin security policy of browsers, which
prevents a page from accessing data from another server. This has put a serious limitation
on Ajax developers: you can use XmlHttpRequests to make background calls to a server, but
it has to be the same server that served up the current page. For more details, you can
visit <ulink
url="http://www.mozilla.org/projects/security/components/same-origin...;.
- </para>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/eXoJCR/ajax.gif" />
- </imageobject>
+ <title>Framework for cross-domain AJAX</title>
+ <para>
+ (<ulink
url="https://anonsvn.jboss.org/repos/exo-jcr/ws/trunk/exo.ws.framewo...>)
+ </para>
+ <section
id="sect-Reference_Guide-Framework_for_cross_domain_AJAX-Motivation">
+ <title>Motivation</title>
+ <para>
+ XmlHttpRequest objects are bound by the same origin security policy of
browsers, which prevents a page from accessing data from another server. This has put a
serious limitation on Ajax developers: you can use XmlHttpRequests to make background
calls to a server, but it has to be the same server that served up the current page. For
more details, you can visit <ulink
url="http://www.mozilla.org/projects/security/components/same-origin...;.
+ </para>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/eXoJCR/ajax.gif" />
+ </imageobject>
- </mediaobject>
- <para>
- But actually writing client web applications that use this object can be tricky given
restrictions imposed by web browsers on network connections across domains. So you need to
find the way to bypass this limitation of AJAX.
- </para>
+ </mediaobject>
+ <para>
+ But actually writing client web applications that use this object can be
tricky given restrictions imposed by web browsers on network connections across domains.
So you need to find the way to bypass this limitation of AJAX.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-Framework_for_cross_domain_AJAX-Scheme_how_it_works">
- <title>Scheme (how it works)</title>
- <para>
- To describe our method for cross-domain AJAX solution, let's consider the
following scheme contains of 3 components:
- </para>
- <para>
- 1). User agent (a browser).
- </para>
- <para>
- 2). ServerA contains a main page with dedicated client and server IFRAMEs (see below)
and an HTML client page (client.html) referenced from the client IFRAME. This client page
contains dedicated script to push the data for request into server IFRAME.
- </para>
- <para>
- 3). ServerB contains remote service that want get access to and an HTML server page
(server.html) referenced from the server IFRAME. This server page contains dedicated
script to push the requested data into client IFRAME.
- </para>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/eXoJCR/ajax-how-it-works.png"
width="444" />
- </imageobject>
+ </section>
+
+ <section
id="sect-Reference_Guide-Framework_for_cross_domain_AJAX-Scheme_how_it_works">
+ <title>Scheme (how it works)</title>
+ <para>
+ To describe our method for cross-domain AJAX solution, let's consider the
following scheme contains of 3 components:
+ </para>
+ <para>
+ 1). User agent (a browser).
+ </para>
+ <para>
+ 2). ServerA contains a main page with dedicated client and server IFRAMEs
(see below) and an HTML client page (client.html) referenced from the client IFRAME. This
client page contains dedicated script to push the data for request into server IFRAME.
+ </para>
+ <para>
+ 3). ServerB contains remote service that want get access to and an HTML
server page (server.html) referenced from the server IFRAME. This server page contains
dedicated script to push the requested data into client IFRAME.
+ </para>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/eXoJCR/ajax-how-it-works.png"
width="444" />
+ </imageobject>
- </mediaobject>
+ </mediaobject>
- </section>
-
- <section
id="sect-Reference_Guide-Framework_for_cross_domain_AJAX-A_Working_Sequence">
- <title>A Working Sequence:</title>
- <para>
- 1) A Browser requests the Start page from the ServerA
- </para>
- <para>
- 2) The Start page is retrieved from the ServerA.
- </para>
- <para>
- 3) Create in the start page IFRAME (name it - "client iframe") and insert it
in the document from ServerA (client.
- </para>
- <para>
- 4) In "client iframe" create ne IFRAME element ("server iframe")
and insert it in the document from ServerB (server.html). Documents (client.html and
server.html) contain special script that can transfer data between iframes.
- </para>
- <para>
- 5) "Client iframe" transfer information about HTTP method and URL that we
want do cross-domain request to "server iframe".
- </para>
- <para>
- 6) "Server iframe" do simple XmlHttpRequest to the service that we need (it
can do that because download from same domain) and get information from service.
- </para>
- <para>
- 7) "Server iframe" transfer data to "client iframe" and now we get
information that we want.
- </para>
+ </section>
+
+ <section
id="sect-Reference_Guide-Framework_for_cross_domain_AJAX-A_Working_Sequence">
+ <title>A Working Sequence:</title>
+ <para>
+ 1) A Browser requests the Start page from the ServerA
+ </para>
+ <para>
+ 2) The Start page is retrieved from the ServerA.
+ </para>
+ <para>
+ 3) Create in the start page IFRAME (name it - "Client iFrame") and
insert it in the document from ServerA (client.
+ </para>
+ <para>
+ 4) In "Client iFrame" create new IFRAME element ("Server
iFrame") and insert it in the document from ServerB (server.html). Documents
(client.html and server.html) contain special script that can transfer data between
iFrames.
+ </para>
+ <para>
+ 5) "Client iFrame" transfer information about HTTP method and URL
that we want do cross-domain request to "Server iFrame".
+ </para>
+ <para>
+ 6) "Server iFrame" do simple XmlHttpRequest to the service that we
need (it can do that because download from same domain) and get information from service.
+ </para>
+ <para>
+ 7) "Server iFrame" transfer data to "Client iFrame" and
now we get information that we want.
+ </para>
- </section>
-
- <section
id="sect-Reference_Guide-Framework_for_cross_domain_AJAX-How_to_use_it">
- <title>How to use it</title>
- <para>
- 1). Place the file client.html and xda.js on the serverA.
- </para>
- <para>
- 2). Place the file server.html on the serverB.
- </para>
- <para>
- 3). Declare xda.js in the main page.
- </para>
-
+ </section>
+
+ <section
id="sect-Reference_Guide-Framework_for_cross_domain_AJAX-How_to_use_it">
+ <title>How to use it</title>
+ <para>
+ 1). Place the file client.html and xda.js on the serverA.
+ </para>
+ <para>
+ 2). Place the file server.html on the serverB.
+ </para>
+ <para>
+ 3). Declare xda.js in the main page.
+ </para>
+
<programlisting language="HTML" role="HTML"><script
type="text/javascript"
src="xda.js"></script></programlisting>
- <para>
- 4). Create JS function which performs cross domain call as in the following example:
- </para>
-
+ <para>
+ 4). Create JS function which performs cross domain call as in the following
example:
+ </para>
+
<programlisting language="Java" role="Java"><script
type="text/javascript">
function test(){
var facade = xdaInit();
@@ -105,13 +105,13 @@
xda.create(facade);
}
</script></programlisting>
- <para>
- 5). Use this function (here it is bound to a button's onclick event).
- </para>
-
+ <para>
+ 5). Use this function (here it is bound to a button's onclick event).
+ </para>
+
<programlisting language="HTML" role="HTML"><button
onclick='test()'>test
cross-domain</button></programlisting>
- </section>
+ </section>
</chapter>