Author: taylor
Date: Mon Apr 30 16:29:56 2007
New Revision: 533879
URL: http://svn.apache.org/viewvc?view=rev&rev=533879
Log:
J1 -> J2 migration guide (finally, this one was long overdue, and im not
talking about me falling behind last week!)
Added:
portals/jetspeed-2/trunk/xdocs/j1-migration.xml
Modified:
portals/jetspeed-2/trunk/xdocs/navigation.xml
Added: portals/jetspeed-2/trunk/xdocs/j1-migration.xml
URL:
http://svn.apache.org/viewvc/portals/jetspeed-2/trunk/xdocs/j1-migration.xml?view=auto&rev=533879
==============================================================================
--- portals/jetspeed-2/trunk/xdocs/j1-migration.xml (added)
+++ portals/jetspeed-2/trunk/xdocs/j1-migration.xml Mon Apr 30 16:29:56 2007
@@ -0,0 +1,1074 @@
+<?xml version="1.0"?>
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<document>
+ <properties>
+ <title>Jetspeed-1 Migration Guideline</title>
+ <subtitle>Migration Guide from Jetspeed 1 to Jetspeed
2</subtitle>
+ <authors>
+ <person name="David Sean Taylor" email="[EMAIL
PROTECTED]" />
+ </authors>
+ </properties>
+ <body>
+ <section name="Overview">
+ <p>This migration guide will help you migrate from Jetspeed version
1 to Jetspeed version 2.
+ Note that there are currently no migration tools, nor are the plans
to create a migration tool to convert
+ portal resources from version 1 to version 2. This document
provides only guidelines for migration.
+ </p>
+ <p>
+ With the development of the new portal standard (The Portlet
API), the common portlet metaphor
+ has changed quite drastically from the Turbine-based origins in
version 1.
+ The programming API is completely changed. There are no longer
XREG files, but instead standard deployment descriptors.
+ The are also new concepts introduced by the portlet standard
such as portlet applications, portlet preferences,
+ user attributes and init parameters that have no direct mapping
from version 1. Creating a migration tool would
+ be a large undertaking. The Jetspeed development team is not
prepared to make this investment.
+ By following the guidelines provided here, you can easily
migrate your Jetspeed 1.x applications to Jetspeed 2.
+ For an overview of architectural differences, see the document
<a href='j1-users.html'>For Jetspeed-1 Users</a>
+ </p>
+ </section>
+ <section name='Migration Table'>
+ <p>The table below gives you an idea of how to migrate. We will
cover each subject in more detail further on in this document.</p>
+ <table>
+ <tr><th>1.x Feature</th><th>2.x
Feature</th><th>Description</th></tr>
+ <tr><td>J1 Portlet Java Code</td>
+ <td>Portlet API Standard Code</td>
+ <td>Rewrite the java code to the new specification.
+ Involves replacing Turbine action with standard
processAction, and replacing Rundata with PortletRequest/Response</td></tr>
+ <tr><td>XREG Portlet Registry</td>
+ <td>portlet.xml deployment descriptor</td>
+ <td>There are pretty big differences here. Migrate
<portlet-entry> to <portlet> entries, <parameter> to
<preference> or <init-param>
+ </td>
+ </tr>
+ <tr><td>J1 PSML</td>
+ <td>J2 PSML</td>
+ <td>Migrate Tabs to Folders and Pages, migrate to new tag
syntax</td>
+ </tr>
+ <tr><td>XREG Security Registry</td>
+ <td>Security Constraints</td>
+ <td>Migrate J1 security constraint format to J2 security
constraint format</td>
+ </tr>
+ <tr><td>J1 Controllers</td>
+ <td>J2 Layouts</td>
+ <td>Controllers are deprecated. Recommend using the new
Jetspeed-2 Layout portlets. If porting necessary, HTML portions of VM code may
port, but not context model variables</td>
+ </tr>
+ <tr><td>J1 Controls</td>
+ <td>J2 Portlet Decorators</td>
+ <td>Controls are deprecated. Recommend using the new Jetspeed-2
Portlet Decorators. If porting necessary, HTML portions of VM code will port,
but not context model variables</td>
+ </tr>
+ <tr><td>J1 Layouts, Screens, Navigations</td>
+ <td>J2 Page (Layout) Decorators</td>
+ <td>All deprecated. Recommend using the new Jetspeed-2 Page
(Layout) Decorators as a starting point to writing your own page decorators.
HTML portions of VM code will port, but not context model variables</td>
+ </tr>
+ </table>
+ </section>
+ <section name="Portlet Applications">
+ <p>One of the most important differences in writing
Jetspeed-2/Portlet API portlets is that you must package your portlet code
+ separate from the Jetspeed portal. In Jetspeed-1, all the user
code, the portlet business logic, is packaged in one big war file
+ mixed in with the Jetspeed-1 implementation. The Portlet API
clearly abolishes this practice of mixing the portal implementation with
+ your portlets. Jetspeed-2 is packaged as a single web
application itself. When you write your portlets for Jetspeed-2, you will need
to
+ write and package your own portlets. The portlet classes and
deployment descriptors must all be packaged into a single war file, known
+ as a portlet application. A portlet application contains one or
more portlets, along with a deployment descriptor, the portlet.xml.
+ A portlet application is an extension of a web application. The
portlet.xml holds the definitions of one or more portlets and is
+ analogous to the xreg files used in Jetspeed-1.
+ </p>
+ </section>
+ <section name="Java Code">
+ <p>In this section we demonstrate how to convert a
Jetspeed-1 portlet to a JSR-168 Java Standard Portlet.
+ This involves the following steps:
+ </p>
+ <ul>
+ <li>Converting the Portlet Init Java Code</li>
+ <li>Converting the Portlet getContent Java Code</li>
+ <li>Converting a Turbine Action</li>
+ </ul>
+ <p>
+ Jetspeed-1 portlet implementations are normally
separated between two different Java source files.
+ </p>
+ <ul>
+ <li>The Portlet Source Code</li>
+ <li>The Turbine Action Source Code</li>
+ </ul>
+ <p>
+ The Portlet Source Code handles the <b>View</b> part of
the MVC pattern. The <b>getContent</b> method
+ is the standard method in Jetspeed-1 to call to render
the content of a portlet. The corresponding methods
+ in Jetspeed-2 and in the Portlet API, the <b>doView,
doEdit, doHelp</b>. In the Portlet API terminology,
+ this phase of portlet processing is known as the
<b>render phase</b>. During the render phase, the portlet
+ should not perform any business logic or other
manipulation on the <b>Model</b>. All model manipulation
+ should be left to the <b>action phase</b>
+ </p>
+ <p>The Turbine Action performs the <b>action phase</b>
of the portlet processing. During the action phase of the Portlet API standard,
+ rendering of all other portlets is blocked until the
action completes. This is also true in the Jetspeed-1/Turbine model.
+ </p>
+ <subsection name='Creating a new Portlet Class'>
+ <p>The best place to get started in migrated your
portlet is to create a new JSR-168 standard portlet.
+ Simply create a new Java class inheriting from the
GenericPortlet interface provided by the Portlet API.
+ You can also use one of the frameworks or bridges
available from Apache Portals or Spring MVC.
+ The example below writes directly to the Portlet API.
The code below can be used a skeleton for writing
+ a portlet.
+ </p>
+<source>
+<![CDATA[
+import java.io.IOException;
+import javax.portlet.GenericPortlet;
+import javax.portlet.PortletConfig;
+import javax.portlet.PortletException;
+import javax.portlet.RenderRequest;
+import javax.portlet.RenderResponse;
+import javax.portlet.ActionRequest;
+import javax.portlet.ActionResponse;
+
+public class HelloWorld extends GenericPortlet
+{
+ public void init(PortletConfig config)
+ throws PortletException
+ {
+ }
+ public void doEdit(RenderRequest request, RenderResponse response)
+ throws PortletException, IOException
+ {
+ }
+ public void doHelp(RenderRequest request, RenderResponse response)
+ throws PortletException, IOException
+ {
+ }
+ public void doView(RenderRequest request, RenderResponse response)
+ throws PortletException, IOException
+ {
+ }
+ public void processAction(ActionRequest request, ActionResponse
actionResponse)
+ throws PortletException, IOException
+ {
+ }
+}
+]]>
+</source>
+ <p>To find out more about Portals Bridges and other
Frameworks, explore these links:
+ </p>
+ <ul>
+ <li><a
href='http://portals.apache.org/bridges/'>Portals Bridges</a></li>
+ <li><a
href='http://portals.apache.org/bridges/multiproject/portals-bridges-jsf/index.html'>JSF
Bridge</a></li>
+ <li><a
href='http://portals.apache.org/bridges/multiproject/portals-bridges-struts/index.html'>Struts
Bridge</a></li>
+ <li><a
href='http://portals.apache.org/bridges/multiproject/portals-bridges-velocity/index.html'>Velocity
Bridge</a></li>
+ <li><a
href='http://www.springframework.org/docs/reference/portlet.html'>Spring
Portlet MVC</a></li>
+ </ul>
+ </subsection>
+ <subsection name='Converting the Portlet Init Java
Code'>
+ <p>
+ The Portlet Source code handles the <b>Init</b> phase
of a portlet lifecycle.
+ The init phase is very similar in both the Java Portlet
API and in Jetspeed 1.
+ Here we have an example of the init method of a
Jetspeed-1 portlet:
+ </p>
+ <source>
+<![CDATA[
+ public void init() throws PortletException
+ {
+ }
+]]>
+ </source>
+ <p>
+ The equivalent method in the Portlet API (Jetspeed-2)
would be, note the difference being the PortletConfig parameter
+ (although the exception classes are named the same,
they are entirely different classes, one from Jetspeed-1, the other from the
Portlet API):
+ </p>
+ <source>
+<![CDATA[
+ public void init(PortletConfig config)
+ throws PortletException
+ {
+ }
+]]>
+ </source>
+ <p>In Jetspeed-1, you would normally access Turbine
Services with static acccessors, for example:</p>
+<source>
+<![CDATA[
+ JetspeedSecurity.addUser(user);
+]]>
+</source>
+ <p>In Jetspeed-2, Jetspeed Services the standard way to
access Jetspeed Services is to get a handle in the init phase, for example:</p>
+<source>
+<![CDATA[
+ private UserManager userManager;
+...
+ public void init(PortletConfig config)
+ throws PortletException
+ {
+ userManager =
(UserManager)getPortletContext().getAttribute(CommonPortletServices.CPS_USER_MANAGER_COMPONENT);
+ if (null == userManager)
+ {
+ throw new PortletException("Failed to find the User Manager on
portlet initialization");
+ }
+ }
+]]>
+</source>
+ </subsection>
+ <subsection name='Converting the Portlet getContent
Java Code'>
+ <p>
+ In Jetspeed-1, the <b>getContent</b> method renders the
content of your portlet. The render phase of Jetspeed-1 is implemented
+ by the getContent method of your Portlet as defined by
the Jetspeed-1 Portlet interface.
+ </p>
+<source>
+<![CDATA[
+public ConcreteElement getContent(RunData rundata);
+]]>
+</source>
+<p>The only parameter passed in to the getContent method is a <b>RunData</b>
parameter. RunData is a part of the <a
href='http://jakarta.apache.org/turbine/'>Turbine web framework</a>.
+RunData is basically a wrapper around the Servlet request and response, along
with other Turbine-specific information.
+When writing portlets for Jetspeed-2, you write to the Portlet API.
+</p>
+<source>
+<![CDATA[
+public void doView(RenderRequest request, RenderResponse response)
+throws PortletException, IOException
+{
+ response.setContentType("text/html");
+ ...
+]]>
+</source>
+<p>The <b>doView</b> method is the Portlet API equivalent of the
<b>getContent</b> method of the Jetspeed-1 API.
+The Portlet API has the concept of <b>portlet modes</b>. There are three
default portlet modes <b>view, edit, and help</b>.
+For each of these modes, there are three methods you can override in your
portlet: <b>doView, doEdit and doHelp</b>.
+Notice that where the Jetspeed-1 API has one RunData parameter, the Portlet
API is more like the Servlet API, with two parameters,
+the <b>RenderRequest</b> and <b>RenderResponse</b>. One of the biggest parts
of migrating your app will be to convert RunData references
+to RenderRequests and RenderResponses. Before starting, we recommend taking a
training course on the Portlet API, or learning the API
+yourself by reading the Portlet specification as well as any articles or books
on the subject. A good book to get started on the Portlet API
+is <a href='http://www.manning.com/hepper/'>Portlets and Apache Portals</a>.
+</p>
+<p>When rendering content, Jetspeed 1 makes use of a HTML construction kit
called <b>ECS</b>. All rendering goes through Turbine and ECS.
+The return type of the getContent method is a <b>ConcreteElement</b>, which is
defined in the ECS API. Here is the typical way to
+generate output from a portlet in Jetspeed-1:
+</p>
+<source>
+<![CDATA[
+...
+String helloString = "Hello World. This is the portlet output in view mode.";
+return new org.apache.jetspeed.util.JetspeedClearElement(helloString);
+]]>
+</source>
+<p>When rendering content in Jetspeed-2, the Portlet API uses a streaming
interface:</p>
+<source>
+<![CDATA[
+response.setContentType("text/html");
+String helloString = "Hello World. This is the portlet output in view mode.";
+
+// using Java writers
+response.getWriter().println(helloString);
+
+.. OR ...
+
+// using Java streaming
+response.getPortletOutputStream().write(helloString.getBytes());
+]]>
+</source>
+<p>Of course you can use JSPs or Velocity with either Jetspeed-1 or
Jetspeed-2.
+With Jetspeed-1, the common practice is to make use of the Jetspeed-1
<b>GenericMVCPortlet</b> or one of its derivitives,
+the <b>VelocityPortlet</b> or the <b>JspPortlet</b>. Both the VelocityPortlet
and JspPortlet are really just GenericMVCPortlets.
+Here is the xreg example of a WeatherPortlet which extends the
GenericMVCPortlet by setting its parent to Velocity
+</p>
+<source>
+<![CDATA[
+ <portlet-entry name="WeatherPortlet" hidden="false" type="ref"
parent="Velocity" application="false">
+ <parameter name="template" value="weather" hidden="true"/>
+ </portlet-entry>
+]]>
+</source>
+<p>The template parameter is named <b>weather</b>. Since this is a Velocity
MVC portlet, Jetspeed-1 knows to look under
+the <b>WEB-INF/templates/vm/portlets/html</b> directory to find
<b>weather.vm</b>. The MVC portlet will automatically handle
+the details of dispatching to this Velocity template to render your portlet.
Here is the actual contents of the velocity template.
+Note that we don't have to write any portlet Java code in this case, but only
the actual template.
+</p>
+<source>
+<![CDATA[
+#if (!$weather_city_info)
+<BR>${l10n.WEATHER_PLEASE_CUSTOMIZE_YO_VM}<br><BR>
+#else
+<a href="http://www.wunderground.com/${weather_city_info}.html";
+target="_blank"><img
src="http://banners.wunderground.com/banner/${weather_style}/language/www/${weather_city_info}.gif";
+alt="Click for ${weather_city_info} Forecast" border="0"></a>
+#end
+]]>
+</source>
+<p>With Jetspeed-2 and the Portlet API, we can make use of the Velocity Bridge
or the JSP Bridge to delegate to portlets.
+The simplest case is just dispatching the call yourself to the JSP or Velocity
servlet. Here is an example of dispatching to a JSP from the doView:
+</p>
+<source>
+<![CDATA[
+protected void doView(RenderRequest request, RenderResponse response) throws
PortletException, IOException
+{
+ PortletContext context = getPortletContext();
+ ResourceBundle resource =
getPortletConfig().getResourceBundle(request.getLocale());
+ request.setAttribute("viewMessage",
resource.getString("preference.label.MyModeIsView"));
+ PortletRequestDispatcher rd =
context.getRequestDispatcher("/WEB-INF/demo/preference/pref-view.jsp");
+ rd.include(request, response);
+}
+]]>
+</source>
+<p>And here is an example of the WeatherPortlet extending the Velocity Bridge,
and making use of the Portlet API User Preferences feature,
+note that we do not directly create a dispatcher here, but the framework will
do that automatically:
+</p>
+<source>
+<![CDATA[
+import org.apache.portals.bridges.velocity.GenericVelocityPortlet;
+...
+
+public class WeatherPortlet extends GenericVelocityPortlet
+{
+...
+
+public void doView(RenderRequest request, RenderResponse response)
+ throws PortletException, IOException
+{
+ Context context = super.getContext(request);
+
+ String cityInfo = (String) request.getPortletSession().getAttribute(
+ WEATHER_CITY_INFO);
+
+ PortletPreferences prefs = request.getPreferences();
+ String city = prefs.getValue(WEATHER_CITY, "Bakersfield");
+ String state = prefs.getValue(WEATHER_STATE, "CA");
+ String station = prefs.getValue(WEATHER_STATION, null);
+ cityInfo = getCityInfo(city, state, station);
+ context.put(WEATHER_CITY_INFO, cityInfo);
+
+ String style = prefs.getValue(WEATHER_STYLE, "infobox");
+ context.put(WEATHER_STYLE, style);
+ response.setProperty("david", "taylor");
+ super.doView(request, response);
+}
+]]>
+</source>
+<p>And here is the Velocity template to render the portlet content:</p>
+<source>
+<![CDATA[
+#if (!$weather_city_info)
+Please configure your Weather settings.
+#else
+<a href="http://www.wunderground.com/${weather_city_info}.html";
+target="_blank"><img
src="http://banners.wunderground.com/banner/$!weather_style/language/www/${weather_city_info}.gif";
+alt="Click for $weather_city_info Forecast" border="0"></a>
+#end
+]]>
+</source>
+ </subsection>
+ <subsection name='Converting a Turbine Action'>
+<p>The Portlet API defines several phases of execution during the processing
of a portlet page. The action phase is designed to be executed
+before the render phase of a portlet. There can only be one action phase
targeting only one portlet. Once the action phase completes, then
+the render phase for all portlets on a page can be executed. Thus the action
phase is said to be a <i>blocking</i> phase, meaning that it must
+complete before the render phase for each portlet on the page can commence.
Actions are usually some kind of user interaction that manipulates
+the <i>Model</i> of the MVC framework, such as a user submitting a form and
updating the model, or adding or deleting a record. The concept
+of actions ports fairly well from Turbine and Jetspeed-1 to Jetspeed-2 and the
Portlet API. Whereas Turbine has the concept of one class per
+action, the Portlet API has an entry point for all actions to come through as
a method on your portlet. Frameworks such as the Spring MVC
+framework provide better abstractions for modeling one method per action.
+</p>
+<p>Lets again look at the WeatherPortlet with Jetspeed-1. First the xreg
defines the actions:</p>
+<source>
+<![CDATA[
+ <parameter name="action" value="portlets.WeatherAction" hidden="true"/>
+]]>
+</source>
+<p>
+We must then implement the action class which are usually placed in the
Jetspeed-1 webapp class loader space.
+Here is the code for the WeatherAction, which extends a Jetspeed-1 framework
class VelocityPortletAction:
+</p>
+<source>
+<![CDATA[
+public class WeatherAction extends VelocityPortletAction
+{
+
+ protected void buildNormalContext( VelocityPortlet portlet,
+ Context context,
+ RunData rundata )
+ {
+
+ String cityInfo = PortletConfigState.getParameter(portlet, rundata,
WEATHER_CITY_INFO, null);
+ //if (cityInfo == null)
+ //{
+ String city =
portlet.getPortletConfig().getInitParameter(WEATHER_CITY);
+ String state =
portlet.getPortletConfig().getInitParameter(WEATHER_STATE);
+ String station =
portlet.getPortletConfig().getInitParameter(WEATHER_STATION);
+ cityInfo = getCityInfo(city, state, station);
+ //}
+ context.put(WEATHER_CITY_INFO, cityInfo);
+ //PortletConfigState.setInstanceParameter(portlet, rundata,
WEATHER_CITY_INFO, cityInfo);
+
+ String style = PortletConfigState.getParameter(portlet, rundata,
WEATHER_STYLE, "infobox");
+ context.put(WEATHER_STYLE,style);
+ }
+]]>
+</source>
+<p>
+In Jetspeed-1 there is some really bad architecture interfering with easily
writing portlets.
+Here in our action, we are actually implementing the <b>View</b> portion of
our code by populating the
+Velocity context with <b>context.put</b> statements. Please beware that all
code implemented in the
+<b>buildNormalContext</b> method should be ported to the <b>doView</b> method
of the Portlet API.
+Note how the actual portlet must be passed in as the first parameter to the
buildNormalContext method.
+</p>
+<p>The actual action code implemented as <b>do..</b> methods on your action
class will need to be ported
+to the <b>processAction</b> method on the Portlet API.
+</p>
+<source>
+<![CDATA[
+ public void doInsert(RunData rundata, Context context)
+ throws Exception
+ {
+]]>
+</source>
+<p>The <b>doInsert</b> method is linked by Turbine to an action in the
Velocity template with the <b>eventSubmit_</b> prefix:
+</p>
+<source>
+<![CDATA[
+<input type="submit" name="eventSubmit_doInsert"
value="${l10n.USER_FORM_ADD_USER_VM}"/>
+]]>
+</source>
+<p>Here is the equivalent in the Portlet API (Jetspeed-2):</p>
+<source>
+<![CDATA[
+ public void processAction(ActionRequest actionRequest, ActionResponse
actionResponse)
+ throws PortletException, IOException
+]]>
+</source>
+<p>The Portlet API provides two parameters to the processAction method: the
ActionRequest and ActionResponse.</p>
+ </subsection>
+ <subsection name='Request Parameters, Portlet Modes,
Window States'>
+ <p>Request parameters are accessed via RunData in
Jetspeed-1:</p>
+<source>
+<![CDATA[
+ String name = rundata.getParameters().getString("username");
+]]>
+</source>
+ <p>With the Portlet API, portlet request parameters are
accessed via the ActionRequest:</p>
+<source>
+<![CDATA[
+ String name = actionRequest.getParameter("username");
+]]>
+</source>
+ <p>With the Portlet API, you can check the Portlet Mode
or Window State:</p>
+<source>
+<![CDATA[
+ if (actionRequest.getPortletMode() == PortletMode.EDIT)
+ {
+ if ( !request.getWindowState().equals(WindowState.MINIMIZED))
+ {
+ ...
+]]>
+</source>
+ <p>The basic Portlet API does not have a way to map
actions to methods as in Jetspeed-1.
+ If you would like this kind of behavior, we recommend
using the <a
href='http://www.springframework.org/docs/reference/portlet.html'>Spring MVC
Portlet framework</a>
+ Here we demonstrate using portlet request parameters
per form to map to specific actions:
+ </p>
+<source>
+<![CDATA[
+ String action =
actionRequest.getParameter(SecurityResources.PORTLET_ACTION);
+ if (action != null && action.equals("remove.user"))
+ {
+ removeUser(actionRequest, actionResponse);
+ }
+ else if (action != null && action.equals("add.new.user"))
+ {
+ PortletMessaging.cancel(actionRequest,
SecurityResources.TOPIC_USERS, SecurityResources.MESSAGE_SELECTED);
+ }
+ else if (action != null && action.equals("add.user"))
+ {
+ addUser(actionRequest);
+ }
+ ...
+]]>
+</source>
+ </subsection>
+ <subsection name='Persisting State: The Portlet
Session'>
+ <p>The Portlet API provides built-in support for
persistence of Portlet state in the session.
+ The Portlet Session is similar to the <b>setTemp</b>
methods in Turbine/Jetspeed-1, or the session support built into the Servlet
API.
+ The Session is for persisting state associated with the
current user session. There are two kinds of session state supported by the
Portlet API:
+ </p>
+ <ul>
+ <li>Application Session State: the session variable is
shared by all portlets in a portlet application</li>
+ <li>Portlet Session State: the session variable is
specific to the one portlet instance window</li>
+ </ul>
+ <p>Here is how we would get and set session information
in Jetspeed-1, using the Turbine RunData API. Note that for both Jetspeed-1 and
Jetspeed-2, the
+ object put in the session must be serializable:</p>
+<source>
+<![CDATA[
+ rundata.getUser().setTemp(ACCOUNT_INFO, accountInfo);
+ ...
+ AccountInfo accountInfo =
(AccountInfo)rundata.getUser().getTemp(ACCOUNT_INFO);
+]]>
+</source>
+ <p>In here is the equivalent in Jetspeed-2 using the
Portlet API:</p>
+<source>
+<![CDATA[
+ AccountInfo accountInfo = (AccountInfo)
+ actionRequest.getPortletSession().getAttribute(ACCOUNT_INFO,
PortletSession.PORTLET_SCOPE);
+ -- or --
+ AccountInfo accountInfo = (AccountInfo)
+ actionRequest.getPortletSession().getAttribute(ACCOUNT_INFO,
PortletSession.APPLICATION_SCOPE);
+
+ -- the setters --
+ PortletSession session = actionRequest.getPortletSession();
+ session.setAttribute(ACCOUNT_INFO, accountInfo,
PortletSession.PORTLET_SCOPE);
+ -- or --
+ session.setAttribute(ACCOUNT_INFO, accountInfo,
PortletSession.APPLICATION_SCOPE);
+]]>
+</source>
+ </subsection>
+ <subsection name='Persisting State: User Preferences'>
+ <p>The Portlet API provides a second persistence
mechanism: User Preferences. User Preferences are fields of information stored
on a per user/per portlet window basis.
+ The equivalent in Jetspeed-1 is Portlet Instance data,
which is stored in the Jetspeed-1 Portlet Registry as name/value pair
<b>parameter</b> XML elements.
+ Looking at the XREG file in Jetspeed-1, we have:
+ </p>
+<source>
+<![CDATA[
+ <parameter name="weather_city_info" value="US/IN/Bloomington"
hidden="true"/>
+]]>
+</source>
+ <p>The Portlet API allows you to define default values
for preferences in the portlet.xml deployment descriptor. The user-specific
values are stored in the Jetspeed Preferences database.
+ Here is an example of the default value for a
preference as it would be defined in the deployment descriptor:
+ </p>
+<source>
+<![CDATA[
+ <preference>
+ <name>weather_city</name>
+ <value>Oakland</value>
+ </preference>
+]]>
+</source>
+ <p>Jetspeed-1 provides the <b>PortletInstance</b> interface on
every portlet for accessing preference-like information. Whereas the preference
information is per-user and per-instance in
+ Jetspeed-2, in Jetspeed-1 preference information accessed via
the PortletInstance interface is only per-instance(per PortletWindow) specific.
These values are stored in the PSML file associated
+ with the PortletWindow. Please note that the values can still
be <i>user-specific</i> when you are using the default mechanism for locating
pages, which is by user. This means that in Jetspeed-1
+ preferences (or parameters) are made user-specific by the
nature of how pages are retrieved. Since a page is located under a user home
directory, then the preference is naturally per user.
+ </p>
+ <p>With Jetspeed-1, here we can retrieve PortletInstance
data:</p>
+<source>
+<![CDATA[
+ // where "this" is a Jetspeed-1 Portlet object
+ PortletInstance instance = this.getInstance(rundata);
+ String value = instance.getAttribute("favoriteColor", "blue");
+ -- or --
+ this.getAttribute("favoriteColor", "blue", rundata);
+
+ -- we can set preference data the same way in Jetspeed-1
+ PortletInstance instance = this.getInstance(rundata);
+ instance.setAttribute("favoriteColor", "red");
+ -- or --
+ this.setAttribute("favoriteColor", "red", rundata);
+]]>
+</source>
+ <p>With the Portlet API in Jetspeed-2, we can use the Portlet
Preferences in a more direct manner.
+ Remember that the store() method must always be called after
all modifications to the prefs during a request:</p>
+<source>
+<![CDATA[
+ PortletPreferences prefs = actionRequest.getPreferences();
+ String color = prefs.getAttribute("favoriteColor", "blue");
+ ...
+ prefs.setAttribute("favoriteColor", "red");
+ prefs.store();
+
+ // note that you can also retrieve multivalues for prefs
+ String values[] = actionRequest.getPreferences().getValues("stocks",
defaultValues);
+
+ // or retrieve all preferences as a Map
+ Map allPrefs = actionRequest.getPreferences().getMap();
+]]>
+</source>
+ </subsection>
+ </section>
+ <section name='Registries'>
+ <p>The Jetspeed-1 Registries hold the following
information:</p>
+ <ul>
+ <li>Portlet Definitions</li>
+ <li>Security Definitions</li>
+ <li>Web Clients and Media Type Registries</li>
+ <li>Skins Definitions</li>
+ <li>Controller Definitions</li>
+ <li>Control Definitions</li>
+ </ul>
+ <p>This section will guide you through how to migrate
each of these registries from Jetspeed-1 to Jetspeed-2</p>
+ <subsection name='Portlet Definitions'>
+ <p>Jetpeed-1 requires that all portlets are defined in an XML
file known as an XREG file (XML Registry). Jetspeed-2 stores its portlet
registry in the database.
+ In Jetspeed-1, the XML registry is on the file system under
the jetspeed webapp under WEB-INF/conf.
+ There can be one or more portlet registry entries. All portlets
are defined with the element type <b>portlet-entry</b>.
+ </p>
+ <p>Migrating your Jetspeed-1 portlet registries to Jetspeed-2
registries requires writing a new Portlet API standard <b>portlet.xml</b>
definition file. We do not provide an XSLT transform to do this for you.
+ Whereas the portlet.xml is defined by the Java Standard Portlet
API, Jetspeed allows for additional information to be defined specific to the
Jetspeed portal: the <b>jetspeed-portlet.xml</b> can hold Jetspeed-specific
+ deployment configurations. Some of the XREG elements map to the
portlet.xml, whereas others will map to the jetspeed-portlet.xml as noted in
the tables below.
+ The table below describes how to map each XML attribute of the
<b>portlet-entry</b> element to its equivalent in the Portlet API portlet.xml
or jetspeed-portlet.xml.
+ Note that we are mapping in this table from XML attributes to
XML elements in the portlet.xml or jetspeed-portlet.xml:
+ </p>
+ <table>
+ <tr>
+ <th>J1 Attribute</th>
+ <th>J2 Element</th>
+ <th></th>
+ </tr>
+ <tr>
+ <td>name</td>
+ <td>portlet-name</td>
+ <td>The name of the portlet. This name is unique to each
portlet application, but not unique system-wide.</td>
+ </tr>
+ <tr>
+ <td>hidden</td>
+ <td></td>
+ <td>No equivalent in the Portlet API, not applicable.</td>
+ </tr>
+ <tr>
+ <td>type</td>
+ <td></td>
+ <td>No equivalent in the Portlet API, not applicable.</td>
+ </tr>
+ <tr>
+ <td>parent</td>
+ <td></td>
+ <td>No equivalent in the Portlet API, not applicable.</td>
+ </tr>
+ <tr>
+ <td>application</td>
+ <td></td>
+ <td>No equivalent in the Portlet API, not applicable.</td>
+ </tr>
+ </table>
+ <p>
+ Continuing with the Portlet XREG conversion, lets now look at
how to convert the XML elements of the <b>portlet-entry</b> element.
+ The table below describes how to map each XML element to its
equivalent in the Portlet API portlet.xml:
+ </p>
+ <table>
+ <tr>
+ <th>J1 Element</th>
+ <th>J2 Element</th>
+ <th></th>
+ </tr>
+ <tr>
+ <td>classname</td>
+ <td>portlet-class</td>
+ <td>The implementing Java class. This class will need to be
ported at the source level.</td>
+ </tr>
+ <tr>
+ <td>media-type</td>
+ <td>supports, supports/mime-type, supports/portlet-mode</td>
+ <td>Media types supported by the portlet must be mapped to one
or more <i>supports</i> elements, with subelements of <i>mime-type</i> and
<i>portlet-mode</i> pairs.</td>
+ </tr>
+ <tr>
+ <td>meta-info/title</td>
+ <td>title</td>
+ <td>The title of the Portlet.</td>
+ </tr>
+ <tr>
+ <td>meta-info/description</td>
+ <td>description</td>
+ <td>The description of the portlet</td>
+ </tr>
+ <tr>
+ <td>category</td>
+ <td>portlet-info/keywords</td>
+ <td>Where there are multiple categories elements, keywords are
comma-separated. In Jetspeed-2, you can configure categories in the
Portlet-Selector administrative portlet based on keywords.</td>
+ </tr>
+ <tr>
+ <td>security-ref</td>
+ <td>jetspeed-portlet.xml: js:security-constraint-ref</td>
+ <td>If you port your Security constraints definitions, you can
keep the same security definition names. Just note that security constraint
definitions are referenced from the jetspeed-portlet.xml, not portlet.xml</td>
+ </tr>
+ <tr>
+ <td>parameter</td>
+ <td>init-param</td>
+ <td>Parameters in Jetspeed-1 should normally map to
<i>init-param</i>s in the Portlet API. These are read only values that can only
be changed by the administrator</td>
+ </tr>
+ <tr>
+ <td>[EMAIL PROTECTED]</td>
+ <td>init-param/name</td>
+ <td>The name of the init parameter</td>
+ </tr>
+ <tr>
+ <td>[EMAIL PROTECTED]</td>
+ <td>init-param/value</td>
+ <td>The value of the init parameter</td>
+ </tr>
+ <tr>
+ <td>parameter/meta-info/description</td>
+ <td>init-param/description</td>
+ <td>The description of the init parameter</td>
+ </tr>
+ <tr>
+ <td>parameter</td>
+ <td>portlet-preferences/preference</td>
+ <td>As well as migrating to init-params, parameters may also be
migrated as default preferences. Note that preferences can optionally be
read-only.</td>
+ </tr>
+ <tr>
+ <td>[EMAIL PROTECTED]</td>
+ <td>portlet-preferences/preference/name</td>
+ <td>The name of the preference</td>
+ </tr>
+ <tr>
+ <td>[EMAIL PROTECTED]</td>
+ <td>portlet-preferences/preference/value</td>
+ <td>The value of the preference</td>
+ </tr>
+ <tr>
+ <td>[EMAIL PROTECTED]</td>
+ <td>portlet-preferences/preference/read-only</td>
+ <td>Optionally you map want to map hidden values to read-only
(true/false)</td>
+ </tr>
+ </table>
+ </subsection>
+ <subsection name='Security Definitions'>
+ <p>Jetspeed-1 supports a Security Constraint XML definition
language that is very similiar to the XML security constraint definitions in
Jetspeed-2.
+ Jetpeed-1 requires that all security definitions are defined in
an XML file known as an XREG file (XML Registry). Jetspeed-2 stores its
security registry either in an XML file or in the database.
+ In Jetspeed-1, the XML registry is on the file system under
the jetspeed webapp under WEB-INF/conf.
+ There can be one or more security registry entries. All
security constraints are defined with the element type <b>security-entry</b>.
+ </p>
+ <p>Migrating your Jetspeed-1 security constraints registries to
Jetspeed-2 registries requires writing a new <b>page.security</b> XML
definition file. We do not provide an XSLT transform to do this for you.
+ The table below describes how to map each XML attribute of the
<b>security-entry</b> element to its equivalent in the Portlet API portlet.xml
or jetspeed-portlet.xml.
+ Note that we are mapping in this table from XML attributes to
XML elements in the portlet.xml or jetspeed-portlet.xml:
+ </p>
+ <table>
+ <tr>
+ <th>J1 Attribute</th>
+ <th>J2 Attribute</th>
+ <th></th>
+ </tr>
+ <tr>
+ <td>[EMAIL PROTECTED]</td>
+ <td>[EMAIL PROTECTED]</td>
+ <td>The name of the security constraint definition. This name
is unique to the entire page.security file.</td>
+ </tr>
+ <tr>
+ <td>meta-info/title</td>
+ <td></td>
+ <td>No equivalent in Jetspeed-2, not applicable.</td>
+ </tr>
+ <tr>
+ <td>meta-info/description</td>
+ <td></td>
+ <td>No equivalent in Jetspeed-2, not applicable.</td>
+ </tr>
+ <tr>
+ <td>access</td>
+ <td>security-constraint</td>
+ <td>Jetspeed-1 security-entries contain 0..n <i>access</i>
elements, Jetspeed-2 security-constraint-defs contain 0..n
<i>security-constraint</i> elements.</td>
+ </tr>
+ <tr>
+ <td>[EMAIL PROTECTED]</td>
+ <td>security-constraint/permissions</td>
+ <td>
+ Actions in Jetspeed-1 are called Permissions in Jetspeed-2.
+ Both versions support wildcarding with the * character.
+ <ul>
+ <li>Jetspeed-1 default actions are view, customize,
maximize, minimize, info, close.</li>
+ <li>Jetspeed-2 default permissions are view, edit,
help, print</li>
+ </ul>
+ </td>
+ </tr>
+ <tr>
+ <td>access/[EMAIL PROTECTED]</td>
+ <td>security-constraint/roles</td>
+ <td>Jetspeed-1 constrains by role through <i>allow-if</i>
elements with a <i>role</i> attribute.
+ Jetspeed-2 constrains by role with the <i>roles</i> element and
a comma-separated list of one or more roles</td>
+ </tr>
+ <tr>
+ <td>access/[EMAIL PROTECTED]</td>
+ <td>security-constraint/groups</td>
+ <td>Jetspeed-1 constrains by group through <i>allow-if</i>
elements with a <i>group</i> attribute.
+ Jetspeed-2 constrains by group with the <i>groups</i> element
and a comma-separated list of one or more groups</td>
+ </tr>
+ <tr>
+ <td>access/[EMAIL PROTECTED]</td>
+ <td>security-constraint/users</td>
+ <td>Jetspeed-1 constrains by user through <i>allow-if</i>
elements with a <i>user</i> attribute.
+ Jetspeed-2 constrains by user with the <i>users</i> element and
a comma-separated list of one or more users, or the wildcard * to specify all
users.</td>
+ </tr>
+ <tr>
+ <td>access/allow-if-owner</td>
+ <td>security-constraints/owner</td>
+ <td>You can set the constraint to be only accessible by the
owner of the page. In Jetspeed-1, this is implied by the location of the page.
+ With Jetspeed-2 you must explicity name the owner in the
element text of the owner element.</td>
+ </tr>
+ </table>
+ </subsection>
+ <subsection name='Web Clients and Media Type Registries'>
+ <p>The Web Clients and Media Type registries are already ported
to Jetspeed-2 and a part of the core system.
+ Jetspeed-2 stores these registries in the database. However
these tables can be populated using seed data
+ as described in the section below on seed data.</p>
+ </subsection>
+ <subsection name='Skins'>
+ <p>The Skin registries are not directly portable to Jetspeed-2.
Jetspeed-2 has moved towards a more standard CSS based
+ skinning approach. There are two basic skinning techniques
which can be combined:
+ </p>
+ <ul>
+ <li>1. Portlet API Standard Skins - see PLT.C of the portlet
specification. A standard set of CSS styles are defined for global skinning of
portlet content.</li>
+ <li>2. Jetspeed Decorators - Decorators can define their own
skins which can then be leveraged by portlets by accessing these styles. The
default decorators in Jetspeed also define the PLT.C styles as well</li>
+ </ul>
+ </subsection>
+ <subsection name='Controllers'>
+ <p>Controllers are deprecated in Jetspeed-2. There is no direct
mapping for converting the Java code. Instead you will need to rewrite a new
Layout portlet, or more likely simply use
+ one of the existing Layout Portlets that come with Jetspeed,
which are quite flexible. The default layout portlets in Jetspeed support
multi-column grids, nesting portlets, and complete
+ customization using the Portlet Customizer.
+ </p>
+ </subsection>
+ <subsection name='Controls'>
+ <p>Controls are deprecated in Jetspeed-2. There is no direct
mapping for converting the Java code. Instead you will need to rewrite a new
Portlet decorator, or more likely simply use
+ one of the existing Portlet decorators that come with Jetspeed,
which are quite flexible.
+ </p>
+ </subsection>
+ </section>
+ <section name="PSML">
+ <subsection name="The Jetspeed Sitemap">
+ <p>The Jetspeed Sitemap defines the
navigational space of all pages in the portal.
+ Both versions 1 and 2 have similiar hiearchical
file system-like site maps.
+ Both contain a root folder /, which in turn
contains a tree of subfolders, where each subfolder
+ can contain pages or more subfolders.</p>
+ </subsection>
+ <subsection name="Site Resources">
+ <p>In Jetspeed-2, there is a well-defined
portal resources that do not always have equivalents in Jetspeed-1:
+ <table>
+ <tr><th>2.x</th><th>1.x</th><th>File</th></tr>
+ <tr><td>Page</td><td>Page</td><td>A
<b>.psml</b> file.</td></tr>
+ <tr><td>Folder</td><td>--</td><td>A
<b>folder.metadata</b> file, one per folder, N/A in Jetspeed-1</td></tr>
+ <tr><td>Link</td><td>--</td><td>A <b>.link</b>
file, N/A in Jetspeed-1</td></tr>
+ <tr><td>Menu</td><td>--</td><td>Menus are
defined in folder.metadata, N/A in Jetspeed-1</td></tr>
+ </table>
+ </p>
+ </subsection>
+ <subsection name="Reserved Directories">
+ <p>There are reserved directories available in
both versions. The naming is a little different.
+ Any directory starting with an underscore (_)
in Jetspeed-2 is considered a control directory
+ and can be used by the profiler (see below)
to locate special directories based on runtime criteria
+ such as the user name or the roles of the
user. Jetspeed-1 has a hard-coded set of reserved (control)
+ directories that are hard-coded into the
profiling rules.
+ </p>
+ <table>
+ <tr><th>1.x</th><th>2.x</th><th></th></tr>
+ <tr><td>user</td><td>_user</td><td>Holds all
user folders</td></tr>
+ <tr><td>role</td><td>_role</td><td>Holds all
role folders</td></tr>
+ <tr><td>group</td><td>_group</td><td>Holds
all group folders</td></tr>
+
<td><td>{mediatype}</td><td>_mediatype</td><td>Content per
mime/mediatype</td></td>
+
<tr><td>{language}</td><td>_lanaguage</td><td>Content per language</td></tr>
+
<tr><td>{country}</td><td>_country</td><td>Content per country code</td></tr>
+ </table>
+ <p>
+ Where the J1 directory names are actually the
names of the reserved directory, such as
+ {mediatype} would be actually <b>html</b> or
{language} would be <b>en</b>. J2 requires
+ specifing control directories (_) such as
<b>_mediatype/html</b>, or <b>_language/en</b>
+ </p>
+ </subsection>
+ <subsection name="Profiling">
+ <p>The Profiling algorithm discovers the
correct page to display during a request.
+ J1 has only two hard-coded algorithm for
finding pages:</p>
+ <ul>
+ <li>J1 user/mediatype/language/country
fallback</li>
+ <li>J1 rollback</li>
+ </ul>
+ <p>Note that these settings are system wide and
must be changed on a per portal basis.
+ J1 expects an explicit container order of
mediatype / language / country
+ </p>
+ <p>
+ J2 has a profiling rules engine that takes
dynamic runtime user information, and using profiling rules
+ discovers the rules based on the algorithm
defined in the rules.
+ In J2 profiling rules are defined on a per
user basis, although there is a system-wide default profiling rule.
+ </p>
+ </subsection>
+ <subsection name="Differences in PSML Page">
+ <p>Jetpeed-1 requires that all portlets are defined in an XML file
known as an XREG file (XML Registry). Jetspeed-2 stores its portlet registry in
the database.
+ In Jetspeed-1, PSML files can be stored under the jetspeed
webapp under WEB-INF/psml. Or, Jetspeed-1 supports storing PSML files in the
database.
+ In Jetspeed-2, PSML files can be stored under the jetspeed
webapp under WEB-INF/pages or WEB-INF/min-pages. Or, Jetspeed-2 supports
storing PSML files in the database.
+ </p>
+ <p>Migrating your Jetspeed-1 PSML files to Jetspeed-2 PSML
files requires porting the files manually, or writing a database conversion
utility or XSLT transform. We do not provide an XSLT transform to do this for
you.
+ The table below describes how to map each XML element or
attribute from Jetspeed-1 to Jetspeed-2:
+ </p>
+ <table>
+ <tr>
+ <th>J1 Element</th>
+ <th>J2 Element</th>
+ <th></th>
+ </tr>
+ <tr>
+ <td>portlets</td>
+ <td>page</td>
+ <td>The outermost container of all content found on a PSML
page.</td>
+ </tr>
+ <tr>
+ <td>[EMAIL PROTECTED]</td>
+ <td>[EMAIL PROTECTED]</td>
+ <td>System wide unique identifier for this page.</td>
+ </tr>
+ <tr>
+ <td>metainfo/title</td>
+ <td>title</td>
+ <td>The Page Title.</td>
+ </tr>
+ <tr>
+ <td>security-ref</td>
+ <td>security-constraints/security-constraints-ref</td>
+ <td>The security constraint reference (0..1 in Jetspeed-1, 0..n
in Jetspeed-2)</td>
+ </tr>
+ <tr>
+ <td>control</td>
+ <td>defaults/portlet-decorator</td>
+ <td>Requires porting your controls to J2 portlet decorators, or
at least mapping the names to existing decorators in Jetspeed-2. Or you can use
a global portlet decorator and ignore this optional setting.</td>
+ </tr>
+ <tr>
+ <td>controller</td>
+ <td>defaults/layout-decorator</td>
+ <td>Requires porting your Turbine controllers, screens
navigations to J2 layout(page) decorators, or at least mapping the names to
existing page decorators in Jetspeed-2.
+ Or you can use a global portlet decorator and ignore this
optional setting.</td>
+ </tr>
+ <tr>
+ <td>portlets/portlets/...</td>
+ <td>page/fragment/..., type="layout"</td>
+ <td>Sub-containers of fragments or portlets. In Jetspeed-2,
fragments can be either containers or portlet definitions. Only fragments with
the type of <b>layout</b> can be a container holding more fragments and
containers.</td>
+ </tr>
+ <tr>
+ <td>portlets/portlets/controller</td>
+ <td>page/[EMAIL PROTECTED]@name={layout-name}</td>
+ <td>Controllers roughly map to fragments of type = layout,
named by the name attribute. Note that layouts are implemented as portlets and
must be specified as PA::portlet-name.</td>
+ </tr>
+ <tr>
+ <td>portlets/entry</td>
+ <td>page/fragment/[EMAIL PROTECTED]"portlet"</td>
+ <td>A portlet window on a page.</td>
+ </tr>
+ <tr>
+ <td>[EMAIL PROTECTED]</td>
+ <td>[EMAIL PROTECTED]</td>
+ <td>The system-wide unique ID of the portlet window.</td>
+ </tr>
+ <tr>
+ <td>[EMAIL PROTECTED]</td>
+ <td>[EMAIL PROTECTED]</td>
+ <td>The portlet registry reference. In Jetspeed-2 the name of
the portlet must be specified as PA::portlet-name</td>
+ </tr>
+ <tr>
+ <td>entry/layout/[EMAIL PROTECTED]"column"@value={column}</td>
+ <td>fragment/[EMAIL PROTECTED]"column"@value={column}</td>
+ <td>The property containing the column position</td>
+ </tr>
+ <tr>
+ <td>entry/layout/[EMAIL PROTECTED]"row"@value={row}</td>
+ <td>fragment/[EMAIL PROTECTED]"row"@value={row}</td>
+ <td>The property containing the row position</td>
+ </tr>
+ </table>
+ </subsection>
+ <subsection name="Menus vs Tabs">
+ <p>There is a big difference with the navigational aspects, or
menus, between Jetspeed-1 and Jetspeed-2.
+ Jetspeed-1 restricts menus navigation to navigation amongst
<i>tabs</i>. Tabs are defined within a PSML page.
+ Tabs are simply subcontainers in the PSML page, defined by the
<b>portlets</b> element.
+ Whereas Jetspeed-1 does support navigation to other pages, the
Tabbing Menus do not directly support it without
+ writing a specific portlet to act as an external link.</p>
+ <p>Jetspeed-2 menu navigations map directly onto the Portal
Site. Thus menu tabs represent portal resources.
+ Menus in Jetspeed-2 can point to folders, pages or links. This
more naturally allows the user to navigate
+ over the entire portal site.
+ </p>
+ <p>When migrating PSML files from Jetspeed-1 to Jetspeed-2,
depending on whether you use advanced Jetspeed-1 controllers such as
+ Card or Tab controllers, you may find that the pages do not
port to Jetspeed-2 very well. In consideration of the lack of migration tools,
+ this leaves two immediate options:
+ </p>
+ <ul>
+ <li>Rewrite your PSML files to better map to the Jetspeed-2
site constructs, folders and multiple pages.</li>
+ <li>Enhance Jetspeed-2 to support card and tab controller
behavior</li>
+ </ul>
+ </subsection>
+ </section>
+ <section name="XML API - Seed Data">
+ <p>Jetspeed-2 defines an XML API for populating the initial
"Seed" data for your portal.
+ Populating your seed data via the XML API provides an
alternative to populating database data with database-specific and hard to read
SQL scripts.
+ Additionally, the XML API can be used for importing and
exporting data, or backing up and restoring from your Jetspeed-2 database.
+ </p>
+ <p>
+ The XML API also provides a migration path over the maintenance
cycle of your Jetspeed portal.
+ The XML API was first implemented in version 2.1. To migrate
your data from version 2.1 to 2.2, (if there are any database schema changes),
+ the XML API can be used to migrate (by exporting and importing)
across versions.
+ </p>
+ <p>As of 2.1, the Jetspeed API supports the following
elements:</p>
+ <table>
+ <tr>
+ <th>Element</th>
+ <th>Description</th>
+ </tr>
+ <tr>
+ <td>MimeTypes</td>
+ <td>Mime Types supported by the portal such as text/html,
text/xhtml....</td>
+ </tr>
+ <tr>
+ <td>MediaTypes</td>
+ <td>Mediat Types supported by the portal such as html, xml,
wml...</td>
+ </tr>
+ <tr>
+ <td>Capabilities</td>
+ <td>General capabilities of web clients that access the
portal</td>
+ </tr>
+ <tr>
+ <td>Clients</td>
+ <td>Supported Web Clients by the portal</td>
+ </tr>
+ <tr>
+ <td>Roles</td>
+ <td>Define all roles defined to the initial configuration of
the portal</td>
+ </tr>
+ <tr>
+ <td>Groups</td>
+ <td>Define all groups defined to the initial configuration of
the portal</td>
+ </tr>
+ <tr>
+ <td>Users</td>
+ <td>Define all initial users defined to the initial
configuration of the portal, minimally admin and guest(anon) users</td>
+ </tr>
+ <tr>
+ <td>Permissions</td>
+ <td>Define initial J2EE security policy for this portal. Note
that permissions are turned off by default.</td>
+ </tr>
+ <tr>
+ <td>ProfilingRules</td>
+ <td>Define all the profiling rules in the initial portal such
as role fallback, user-role-fallback, j1-emulation, default-j2, subsites and
more</td>
+ </tr>
+ <tr>
+ <td></td>
+ <td></td>
+ </tr>
+
+ </table>
+ </section>
+ <section name='XML Schemas'>
+ <p>Reference for Jetspeed-2 XML schemas:</p>
+ <table>
+ <tr>
+ <td>Jetspeed-2 PSML</td>
+ <td><a
href='http://portals.apache.org/jetspeed-2/2.1/schema/psml.xsd'>http://portals.apache.org/jetspeed-2/2.1/schema/psml.xsd</a></td>
+ </tr>
+ <tr>
+ <td>Jetspeed-2 Folder Metadata</td>
+ <td><a
href='http://portals.apache.org/jetspeed-2/2.1/schema/folder-metadata.xsd'>http://portals.apache.org/jetspeed-2/2.1/schema/folder-metadata.xsd</a></td>
+ </tr>
+ <tr>
+ <td>Jetspeed-2 Seed Data</td>
+ <td><a
href='http://portals.apache.org/jetspeed-2/2.1/schema/j2-seed.xsd'>http://portals.apache.org/jetspeed-2/2.1/schema/j2-seed.xsd</a></td>
+ </tr>
+ <tr>
+ <td>Jetspeed-2 Security Constraints</td>
+ <td><a
href='http://portals.apache.org/jetspeed-2/2.1/schema/page-security.xsd'>http://portals.apache.org/jetspeed-2/2.1/schema/page-security.xsd</a></td>
+ </tr>
+ <tr>
+ <td>Jetspeed-2 Links</td>
+ <td><a
href='http://portals.apache.org/jetspeed-2/2.1/schema/link.xsd'>http://portals.apache.org/jetspeed-2/2.1/schema/link.xsd</a></td>
+ </tr>
+ <tr>
+ <td>Jetspeed-2 Extended Portlet Descriptor</td>
+ <td><a
href='http://portals.apache.org/jetspeed-2/2.1/schema/jetspeed-portlet.xsd'>http://portals.apache.org/jetspeed-2/2.1/schema/jetspeed-portlet.xsd</a></td>
+ </tr>
+ </table>
+ </section>
+ <section name="Where to Get Started?">
+ <p>The best place to get started is to create your own custom
portal. This process is defined online at Apache. The <a
href='http://portals.apache.org/tutorials/jetspeed-2/'>Jetspeed Tutorial</a>
will take you through
+ the initial steps of setting up your own (custom) Jetspeed
portal, including setting up XML seed data, PSML, custom decorations and
portlet applications.</p>
+ </section>
+ </body>
+</document>
+
Modified: portals/jetspeed-2/trunk/xdocs/navigation.xml
URL:
http://svn.apache.org/viewvc/portals/jetspeed-2/trunk/xdocs/navigation.xml?view=diff&rev=533879&r1=533878&r2=533879
==============================================================================
--- portals/jetspeed-2/trunk/xdocs/navigation.xml (original)
+++ portals/jetspeed-2/trunk/xdocs/navigation.xml Mon Apr 30 16:29:56 2007
@@ -45,6 +45,7 @@
</menu>
<menu name="About Jetspeed-2">
<item name="For Jetspeed-1 Users" href="j1-users.html" />
+ <item name="Jetspeed-1 Migration Guideline"
href="j1-migration.html" />
<item name="Supporting Projects"
href="supporting-projects.html" />
<item name="Who Uses J2?" href="who-uses-j2.html" />
<item name="Portlets Community" href="portlets-community.html"
/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
![http://banners.wunderground.com/banner/${weather_style}/language/www/${weather_city_info}.gif"](http://banners.wunderground.com/banner/${weather_style}/language/www/${weather_city_info}.gif"){kind=link}
![http://banners.wunderground.com/banner/$!weather_style/language/www/${weather_city_info}.gif"](http://banners.wunderground.com/banner/$!weather_style/language/www/${weather_city_info}.gif"){kind=link}