Author: thomas.heute(a)jboss.com
Date: 2007-07-13 05:27:15 -0400 (Fri, 13 Jul 2007)
New Revision: 7748
Modified:
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/migration.xml
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/portalapi.xml
Log:
Doc fixes:
JBPORTAL-1547
JBPORTAL-1548
Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/migration.xml
===================================================================
---
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/migration.xml 2007-07-13
08:26:45 UTC (rev 7747)
+++
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/migration.xml 2007-07-13
09:27:15 UTC (rev 7748)
@@ -53,7 +53,7 @@
are visable. If you use default theme like "renaissance" that is
present in 2.6, you shouldn't need to do anything. To update your custom themes
please
refer to those bundled with portal as an example.
</para>
- <note>If you stay with old theme files you may find JBP 2.6 unusable by
not even be able to log in.</note>
+ <note>If you stay with old theme files you may find JBP 2.6 unusable to
the point that you may not even be able to log in</note>
</sect2>
<sect2>
<title>Database</title>
Modified: docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/portalapi.xml
===================================================================
---
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/portalapi.xml 2007-07-13
08:26:45 UTC (rev 7747)
+++
docs/branches/JBoss_Portal_Branch_2_6/referenceGuide/en/modules/portalapi.xml 2007-07-13
09:27:15 UTC (rev 7748)
@@ -20,10 +20,10 @@
that no changes should be required when code is written against the API provided
by the JBoss Portal
2.x versions and used in a later version of JBoss Portal 2.x.</para>
- <para>The Portal API package prefix is
<emphasis>org.jboss.portal.api</emphasis> and all the classes
- part of the API are prefixed with that package except for two of them which are
the <emphasis>org.jboss.portal.Mode</emphasis>
- and <emphasis>org.jboss.portal.WindowState</emphasis> classes, the
main reason being that twose two classes were defined
- very early before the official Portal API framework was created.</para>
+ <para>The Portal API package prefix is
<emphasis>org.jboss.portal.api</emphasis>. All of the classes that are part
+ of this API are prefixed with this package name except for the
<emphasis>org.jboss.portal.Mode</emphasis>
+ and <emphasis>org.jboss.portal.WindowState</emphasis> classes. These
two classes were defined before the official
+ Portal API framework was created and so the names have been maintained for
backward compatibility.</para>
<para>The Portlet API defines two classes that represents a portion of the
visual state of a Portlet which
are <emphasis>javax.portlet.PortletMode</emphasis> and
<emphasis>javax.portlet.WindowState</emphasis>. Likewise
the Portal API defines similar classes named
<emphasis>org.jboss.portal.Mode</emphasis> and
@@ -104,8 +104,8 @@
</caption>
</mediaobject>
<para>The
<emphasis>org.jboss.portal.api.PortalRuntimeContext</emphasis> gives access to
state or operations
- associated at runtime with the current user of the portal. It allows to retrieve
the user id when the method
- <emphasis>String getUserId()</emphasis> returns a non null string. It
also gives access to the
+ associated at runtime with the current user of the portal. The
<emphasis>String getUserId()</emphasis> retrieve
+ the user id and can return null if no user is associated with the context. It also
gives access to the
<emphasis>PortalSession</emphasis> instance associated with the current
user. Finally it gives access to the
<emphasis>NavigationalStateContext</emphasis> associated with the
current user.</para>
</sect1>
@@ -210,8 +210,8 @@
</mediaobject>
<para>
The
<emphasis>org.jboss.portal.api.event.PortalEventContext</emphasis> interface
defines the context in which
- an event is created and propagated. It allows to retrieve the
<emphasis>PortalRuntimeContext</emphasis> in
- order to obtain the portal context. Note that this method may return null if no
context is available.
+ an event is created and propagated. It allows retrieval of the
<emphasis>PortalRuntimeContext</emphasis> which
+ can in turn be used to obtain the portal context.
</para>
<mediaobject>
<imageobject>
@@ -292,9 +292,9 @@
interface semantic allows only traditional event delivering. The
<emphasis>PortalNodeEventListener</emphasis>
interface is designed to match the bubbling effect during an event
delivery.</para>
<para>The <emphasis>PortalNodeEvent
onEvent(PortalNodeEventContext context, PortalNodeEvent event)</emphasis>
- declare a <emphasis>PortalNodeEvent</emphasis> as return type. In
normal circumstances it will return the
- null value, however if the method call returns an event then this event
should be considered by the portal
- as behavior replacing the current one.
+ method declares a <emphasis>PortalNodeEvent</emphasis> as return
type. Commonly the method returns null;
+ however, a returned PortalNodeEvent replaces the event in the listeners
subsequently called during
+ the event bubbling process.
</para>
</sect3>
<sect3>