© 2007 IBM Corporation
The companies and people in this scenario are fictitious. Actual user interfaces may differ from those depicted here.
WebSphere Portal v6 Unifying people, tools and resources for greater productivity
What you always wanted to know about URIs in WebSphere Portal – or more than that …
Dr. Carsten Leue ([email protected])
WebSphere Portal v6
Why is this presentation interesting?
� Because it answers these questions:
� Why are my portal URLs so long? (short answer: they aren‘t ☺)
� Why do my portal URLs look like random character sequences?
� Are there ways to produce human readable URLs? What are the pros and cons?
� How can URL handling be customized?
� What is the concept behind URL handling in WebSphere Portal?
http://localhost:10038/wps/myportal/!ut/p/c1/04_SB8 K8xLLM9MSSzPy8xBz9CP0os3h3g0ADYzcPIwP30GATAyNT01ADM1NzIwMDc_1wkA6z-DBvw-CwAHcjQwOTAFegCmcPo1ADcwODQGOIvAEO4Gig7-eRn5uqX5CdneboqKgIANkbCCk!/
Typical example of a WebSphere Portal URL
WebSphere Portal v6
Agenda
� State Handling in WebSphere Portal
� Concepts
� APIs
� Different Types of URLs
� Render-URLs and Action-URLs� Rich-URLs and Delta-URLs
� Virtual-Portal URLs� URL-Mappings� Friendly-URLs
� Piece-of-Content URLs
WebSphere Portal v6
Screenshots: Bookmarkability
Note that not only the portal page but also
the state of the portletsis restored.
WebSphere Portal v6
Screenshots: Back-Button Support
The back-button affects every
navigational interaction with the pages or the
portlets
WebSphere Portal v6
Key-Requirements for URL handling
� Back- and Forward-Button Support
� The user can use the browser‘s back and forward buttons to switch between recent „views“
� Bookmarkability
� The „current view“ can be saved into a client side bookmark
� The bookmark can be accessed at any time (probably requires a logon first)
� The bookmark must remain valid across portal versions
� Crawlability
� Web-Crawlers (e.g. Googlebot) can crawl portal pages and index them
� Cacheability
� Views of pages must be cacheable
� Non-Functional Requirements
� Respect URL size limitations (2KB) as imposed by RFC 1738
� Performance during URL generation
WebSphere Portal v6
Key-Concept: Navigational State
� The client requests a view of the portal content by sending a URL
� The server constructs the view based on
�State in the URL (navigational state)�State in the session (more general, based on cookies)�State in the persistence layer (DB)
� Back-button, bookmarks, crawlers, caches only affect the URL
� � the “view” is identified by state in the URL
� � the “content” is provided by long term persistent information (i.e. session and/or DB, LDAP)
DB
session
Portal ServerClient
navigationalstate
sessionstate
persistentstate
ContentView of theContent
WebSphere Portal v6
Navigational State
� Navigational state is all information required to define the „view“ of portal content
� Navigational state is „encoded“ into the URL
� The URL is the only place to store navigational state in � all URLs need to contain the complete navigational state
� The navigational state is the aggregation of
�State managed by WebSphere Portal�State managed by different portlet windows (JSR168 and JSR286)
� Navigational State contains ...
�Page selection�Label selections�Expansion states of navigation�Theme-Template�...�Render Parameters of all visited portlets
Different Navigational State results in different URLs.(but the same Navigational State does not neccessarily result in the same URLs)
This is a lot of information that cannot be handled by the application independently �State handling API
WebSphere Portal v6
Navigational State Processing
� During request processing the URL is decoded into a navigational state-document
� This state-document can be modified during a PreProcessing phase
�Extensible via Eclipse-extension points
� PreProcessing can be used to apply special business logic, e.g.
�reset portlet state or render parameters on page changes�select pages based on URL parameters�etc. ...
RequestStart
DecodeURL
PreProcessNavState
HandleRequest
S1
S2
URL
Can be customizedvia Eclipse extensionpoints (upcoming release)
deco
detr
ansf
orm
WebSphere Portal v6
Navigational State and Crawlability
� How crawlers work
� Crawlers fetch pages via GET requests
� They follow each link that is reachable via GET (idempotent operation)
� If such links point to different URLs they get indexed individually
� What site-owners typically expect
� Every portal page is indexed, but only once
� Effect with Navigational State
� Every navigational state combination is indexed
� As a result a portal page is indexed multiple times, once for every different „view“
The same portal page in differentnavigational states � different URLs
WebSphere Portal v6
Navigational State and Crawlability (cont‘d)
� Goal
� Per default, only the initial view of a page is indexed by a crawler
� Customers can override this behaviour and
� Solution
� WebSphere Portal detects if a crawler requests a page or a browser
� For crawlers the navigational state encoded with a URL is stripped to only contain the page selection
� � State Normalization
� Trivia
� WebSphere Portal has additional crawler support
�Site map�References to the site map in every page (as a hidden link)�Robot directives based on the cache-headers
WebSphere Portal v6
Different Types of URLs
� Render-URLs and Action-URLs
� Rich-URLs and Delta-URLs
� Virtual-Portal URLs
� URL-Mappings
� Friendly-URLs
� Piece-of-Content URLs
WebSphere Portal v6
Two-Phase Processing Model
� The Portal Programming Model distinguishes between two processing phases
� Action Processing
�Modies server side state of resources�Is executed sequentially across all involved resources (e.g. Portlets) to avoid side effects�Since JSR286 the distribution of events is part of the action processing phase�Results in new navigational state
� Rendering
�Requests a view of the addressed resources without modifying them (idempotent operation)�May be executed in parallel on the addressed resources (parallel portlet rendering)
ActionHandling
RequestStart
Decoding
S1
S2
RequestStart
Decoding
Rendering
RequestEnd
S2
Redirect?yes
no
Render- and Action-Phase do NOT neccessarily occur in the same request
Action Request Render Request
This redirec behaviour can be fine-tuned by a number of settings (see info-center)
� redirect.action.without.session
� prohibit.implicit.redirect
� wps.multiple.action.execution
� wps.enforce.redirect
� redirect.command
� avoid.redirect.commands
WebSphere Portal v6
Action URLs
� Actions and events are per design non-idempotent operations
� Their semantic correlates with the „unsafe“ HTTP operations POST, PUT
�� Action SHOULD be represented by markup fragments that result in such HTTP requests, i.e. in FORMs
� Actions can only be triggered by ActionURLs (i.e. URLs that are flagged specifically)
� For security reasons WebSphere Portal has two action-URL-security-mechanisms (next slides):
�Dangerous Action-URL protection�Multiple Action-URL protection
� Examples:
� Performing a logon or a logout
� Creation of a new data record in the DB (e.g. after assembling data in a form)
� Deletion of a DB entry
� Adding an item to a shopping cart (session based)
� Counter Examples:
� Switching pages or views
� Execution of a query (e.g. a search query)
WebSphere Portal v6
URL contains the commandto transfer $1M to from
Alices‘s to Mallory‘s account
Dangerous Action-URL Protection
� Actions are potentially „dangerous“because they modify server side state
�E.g. „buy an item“ or „delete a document“
� Goal: the user must be protected from unintentionally executing an action
�by clicking a link in an E-Mail�by invoking a bookmark�...
� Solution:
� Actions are only executed if the URL that triggers the action has been created in the active session
�If the user has logged in a session is guaranteed to exist�If the user did not log in, actions are unprotected but cannot do harm anyway
Malicious Mallory Naive Alice
CreatesAction URL
SendsURL to Bob
Session 1
ReceivesURL
Session 2
ClicksURL
URLrejected!
Rejected because thesessions don‘t match!
WebSphere Portal v6
Multiple Action-URL protection
� Action URLs are potentially dangerous
� If an action-URL is invoked multiple times unintentionally then this might lead to unexpected results
�E.g. the purchase of more items than expected
� This can happen more-often than expected
�many applications do not consistently represent actions as POST/PUT but sometimes as GET�If represented as GET then the use of the back-button or bookmarks would cause multiple action execution
� Goal : the user should be protected from unintentionally invoking an action multiple times
� Solution:
� Action-URLs are assigned a unique ID
� WebSphere Portal keeps track of the actions-URL that have been invoked during a session and refuses to invoke the same action-URL twice
� Problems with this solution:�The solution assumes that most applications „misbehave“, i.e. not consistently use the HTTP verbs�Well-behaving applications are restricted�There exists a memory overhead in bookkeeping�� multiple-action protection can be disabled on a per-portlet basis
WebSphere Portal v6
Generation of Action-URLs
� In Portlets
� Use the Portlet-API (JSR168, JSR286 or legacy)
�javax.portlet.*
�<portlet:actionURL>
� In exceptional cases use the state-handling API
�com.ibm.portal.state.*
�com.ibm.portal.state.accessors.portlet. PortletTargetAccessorController
� In Themes and Skins
� There should be no need to create portlet action URLs from themes or skins
� In exceptional cases use the state-handling API
<%@ taglib uri="http://java.sun.com/portlet" prefix="portlet" %>
<form method="POST" action=" <portlet:actionURL/>" >
Enter Zip Code:
<input type="text" name="zip" value="">
<input type="submit" name="submit" value="Search">
</form>Act
ion-
UR
L in
a p
ortle
t-JS
P
WebSphere Portal v6
Recommendations
� Always represent actions via the POST or PUT verb
� Enable redirect after the action processing phase
� Disable the multiple action-URL protection feature
� � as a result all URLs in the back-button history or the addressbar (for bookmarking) will be safe render URLs
WebSphere Portal v6
Render URLs
� Render URLs are used to represent idempotent operations
�� there should be no side-effects when invoking a render URL
� Their semantic correlates with the „safe“HTTP operation GET
� Render-URLs are the key to back-button support, bookmarkability and crawlability of portal applications!
� Examples:
� Navigation to different pages or tabs within a portlet
� Search queries
� Expanding/collapsing a tree navigation widget ...
� Basically every interaction that requests a different view of a resource versus modifying the resource
WebSphere Portal v6
URL examples
Navstate: sel=catsSession: empty
Navstate: sel=cartSession: 10 cats
Navstate: sel=dogsSession: empty
Ren
der-
UR
L
Act
ion-
UR
L
WebSphere Portal v6
Generation of Render-URLs
� In Portlets
� Use the Portlet-API (JSR168, JSR286 or legacy)
�javax.portlet.*
�<portlet:renderURL>
� In exceptional cases use the state-handling API
�com.ibm.portal.state.*
�com.ibm.portal.state.accessors.portlet. PortletTargetAccessorController
� For common usecases there exists a easy-to-use convenience API
�com.ibm.portal.portlet.service.url.PortalURLGenerationService
�<portlet-ext:portalRenderURL>
� In Themes
� There should be no need to create portlet action URLs from themes or skins
� In exceptional cases use the state-handling API
<%@ taglib uri="http://java.sun.com/portlet" prefix="portlet" %>
<a href=" <portlet:renderURL><portlet:param name="tab" value="tab-2"/></portlet:renderURL>" >2nd Tab</a>
Ren
der-
UR
L in
a p
ortle
t-JS
P
WebSphere Portal v6
Recommendations
� When designing an application, consider that the same app can be viewed in different state instead of setting the app into a different UI state
� Represent the normalized set of information that identify the different views a navigational state (render parameters for JSR168 portlets)
� Encode changes in different views as render-URLs
� Reserve action-URLs for real state changes in the backend (session, DB)
� Portlets are strongly encouraged to use the Portlet-APIs to generate URLs, only use WebSphere Portal APIs for specific and special usecases
WebSphere Portal v6
Different Types of URLs
� Render-URLs and Action-URLs
� Rich-URLs and Delta-URLs
� Virtual-Portal URLs
� URL-Mappings
� Friendly-URLs
� Piece-of-Content URLs
WebSphere Portal v6
Encoding (format) of URLs
� URLs must contain
�Portal instance identification�Navigational state (i.e. the aggregation of the navigational state of WebSphere Portal and ALL of the targeted applications)�Potentially Action Parameters
� ���� this is a lot of information!
� URL formats
� Rich URLs
�Efficient encoding format that handles the general case. Not targeted for „human deciphering“
� URL Mappings
�Human readable but less functional
� Friendly URLs
�Human readable
� Piece-of-Content URIs
�Late binding mechanism, allow to target „content“ instead of portal artifacts
WebSphere Portal v6
Navigational State
� Navigational state can be regarded as an (XML) document of state-information
� This information needs to be encoded into the URL
�Efficiently wrt. CPU cycles and small URL lengths
� Example:
�1521 Bytes vs 358 bytes
Example State Document, 1521 Bytes
Rich URL: 358 bytes only/c1/lZDRaoMwFIafpQ8wckxidJepbsno7Iwatd6IF6Mos26sdJ1Pv4QyBhYtyyEXh4_v55yDKmTq0JzafXNsh0PzhkpUsVqAAvIoMYDgDLCLSeIpxwEAw3eszjdOmscCO0DjB8MDiTV4AIr8yxZ0fbEJYwERAbP2HOXshk1v2IXddXl2y2HmcZj4frhdW_8eRzLC_hpP-GQCnyxzu_0ip2iHKu_vuv5LQg13tQ59e1yMMlQCrdNufFadP2bdmBXmpyPJIeeKh-dNH32tVpMcodNLDjDXM607k6N_c4aCfx_VVc50Huc6R4khP8sENP_4lOyOm4ytHPpX9N5rXUL71Mb9ydbeoB-InAFV
WebSphere Portal v6
Syntax of Rich-URLs
� Codec
� Identifies the encoding algorithm and the version of the state document
�Backwards compatibilty of URL formats
� A URL may contain more than one codec (they override from left to right)
� Compressed-State
� A gzipped and base64 encoding of a binary XML serialization (non-standard, optimized for WebSphere Portal)
scheme://host:port/ctx/!ut/p( /codec/compressed-state )*
� /!ut/p
� Identifier that denotes the start of the first codec (important for friendly URLs later on)
� The actual token value has „historic“reasons and can be reconfigured by the customer
� /ctx
� The portal context, e.g. /wps/portal
WebSphere Portal v6
Delta-Codecs
� Problem to solve
� The serialization of a full state document is still relatively time consuming
� Needs to be done for EVERY URL on a page, potentially 100‘s
� Solution
� Assume that the state per URL only differs slightly from the state of the request
� Only encode this delta relative to the request state (via <base> tag)
scheme://host:port/ctx/!ut/p/codec/state /delta/state‘
� Challenges with Delta URLs
� Introduces relative URLs and the use the <base> tag. Some ad-hoc Javascript does not work with this.
� Introduces URL aliases and therefore reduces cacheability of pages.
� � delta URLs are enabled per default
� � relative URLs are disabled per default
Constant across all URLs generated during a request Differs per URL
WebSphere Portal v6
The effect of Delta-URLs
Example:Navigation URLs
<a class="wpsNavItem wpsNavLevel1" href=" /wps/myportal/!ut/p/c1/fc3LDoIwEIXhZ_EJ5nSgLS7BS5sYCJWAyIawMIREwIXx-W2Xmuic5Z8vQx35LcNrGofntC7DnVrqVG_gEB0tw9RVDJayhpKaAe37VfXNSVRNaVggLg--7yzX0ICLPjRMqnzl6KydEADoEv7996Hjx6X48sm-yILfcm5zTjKmwq7zjR5zi6kcN2_w0Bjn/ " > PetStore </a>
<a class="wpsNavItem wpsNavLevel1" href=" dl2/d1/L2dJQSEvUUt3QS9ZQnB3LzZfRzBRMDNGSDIwR1VTNDAyNTVVMDY1NzIwMDc!/ " > PetStore </a>
Without Delta-URL With Delta-URL
WebSphere Portal v6
Delta-Codecs: the <base> tag
� Delta codecs add a „/delta/state“suffix to the current URL
�� the final URLs become longer and longer because the delta-suffixes add up
� Solution:
� Each page encodes the normalized state as the <base> tag in the header
� Delta-URLs are suffixes to this <base>tag, not the URL in the address bar
� � Delta-Suffixes are limited to a maximum of one suffix
� Note:
� If custom code (e.g. JS code) follow links, the <base> tag must be respected!
Delta-URL of the requestscheme://host:port/ctx/!ut/p/codec/state/delta/state1
<base href = „scheme://host:port/ctx/!ut/p /codec/state1“ >
Normalized State encoded into the base tag
<a href = „delta/state2“ >Relative URLs reference the base tag
scheme://host:port/ctx/!ut/p/codec/state1/delta/state2
URL of next request
request
apply the delta andcompute the new state
click on the relative URL
equivalent
WebSphere Portal v6
Recommendations
� Design your application such that it respects the <base> tag and can cope with relative URLs
� a common mistake is to pass URLs as parameters to JS functions. Read the hrefattribute of anchor tags instead
� Enable the generation of relative URLs in WebSphere portal
� Use render parameters often, but ...
�... normalize the set of render parameters�... choose short parameter names (no need to make them human readable, use JAVA constants for readability)
WebSphere Portal v6
Different Types of URLs
� Render-URLs and Action-URLs
� Rich-URLs and Delta-URLs
� Virtual-Portal URLs
� URL-Mappings
� Friendly-URLs
� Piece-of-Content URLs
WebSphere Portal v6
Virtual Portals and URLs
� Virtual portals (VP) represent multiple logical portal that run inside the same portal instance
� The content of the VPs is separated from each other
� � each VP is addressable separately via its own URL prefix
� VPs are uniquely identified via an ObjectID . This ID is however not suitable to be used as the address of the ID (because of readability reasons)
clientVirtual Portal 1
Virtual Portal 2
Hosting Portal Server
Default Portal
Shared DB
URL 1
URL 2
URL 3
WebSphere Portal v6
Syntax of Virtual-Portal URLs
� VPName
� A path prefix contains a unique identifier (name) for a VP
� WP determines the VP ID via a name-to-VP mapping table
� The assignment of a hostname and a prefix per VP is mutually exclusive
� Recommendation
� The assignment of a hostname to a VP matches the semantic of a VP better than the prefix mapping � it should be preferred
� Hostname (upcoming)
� Different virtual portals can be addressed via different hostnames
� The HTTP server needs to listen to all hostnames to route the requests to the hosting portal (per default listens to *)
� WP determines the VP ID via a hostname-to-VP mapping table
� In case of proxy servers there exists a public plug-point to let the customer specify how to decode the hostname from the request (e.g. via header)
scheme:// host :port/ctx /vpname /navstate
All access points into WP use the same policy to address VPs,including the REST services.
WebSphere Portal v6
Virtual Portal URLs
http://www.myhost.com/wps/portal/!ut/p/c0/...
http://www.myhost.com/wps/portal/ somevp/!ut/p/c0/...
http:// www.myhost1.com /wps/portal/!ut/p/c0/...
http:// www.myhost2.com /wps/portal/!ut/p/c0/...
The Virtual-Portal-Manager Portlet
Exa
mpl
es
WebSphere Portal v6
Generation of Virtual Portal URLs
� It is not supported (via APIs) to link from one virtual portal into another virtual portal
�VPs are independent, OIDs cannot be queried across VPs so there is no way to address artifacts�Same behaviour as for inter-portal linking
� All URL generation APIs will automatically consider the current VP and add hostname or VP-prefix accordingly
�current = VP of the executing request
WebSphere Portal v6
Different Types of URLs
� Render-URLs and Action-URLs
� Rich-URLs and Delta-URLs
� Virtual-Portal URLs
� URL-Mappings
� Friendly-URLs
� Piece-of-Content URLs
WebSphere Portal v6
URL-Mappings
� URL mappings allow to define human readable URL prefixes that lead to portal pages
� URL mappings can only be used as the entry point into WP, all subsequent URLs lose those prefixes
�Because the mapping is not bijective
� The URL prefixes can form hierarchies
� The topology formed by URL mappings is however uncorrelated with either the navigation or content topology (see friendly URLs)
URL-Mappings Content Nodes
home
shop
shoes
info
/wps/portal /home
/wps/portal /home/shop
/wps/portal /home/shoes
These hierarchies are independent!
WebSphere Portal v6
Syntax of URL-Mappings
� Context-Label
� A path segment that can be chosen by the portal administrator
� The concatenation of all path segments forms the URL-Mapping
scheme://host:port/ctx/vpname (/context-label)*
URL-Mapping
WebSphere Portal v6
Generation and Assignment of URL-Mappings
� URL mappings can be managed via the admin UI, XMLAccess or Scripting
� URL mappings can be hardcoded into HTML markup or published outside of the portal markup
� There is no API to programmatically construct URL-Mapping URLs!
The URL-Mapping Portlet
WebSphere Portal v6
Recommendations
� DOs
� Build a set of user-friendly URLs that can be published (e.g. in print media or bookmark collections)
� Maintain a stable set of URLs that will not change even if the portal site topology changes
� Use as hard-coded entry point URLs, e.g. to link across sites or virtual portals
� DON‘Ts
� Try to keep the structure of the URL mapping hierarchy in sync with the page hierarchy (significant maintenance effort!)
� Consider the URL mappings as „readable names for pages“. These names will not be preserved during navigation.
WebSphere Portal v6
Different Types of URLs
� Render-URLs and Action-URLs
� Rich-URLs and Delta-URLs
� Virtual-Portal URLs
� URL-Mappings
� Friendly-URLs
� Piece-of-Content URLs
WebSphere Portal v6
Friendly-URLs (upcoming)
� Friendly-URLs result in human readable URL prefixes that lead to portal pages
� Each content node might have a friendly name assigned
� The friendly-URL is a hierarchical path constructed from these names based on the content topology (see URL mappings)
� Every URL that is generated by WP APIs will contain the friendly-path automatically
�It is even guaranteed that every URL that leads to a particular page will start with the page‘s friendly-path
Content Nodes
root
home
shop
info
shoes
/wps/portal /home
/wps/portal /home/shop
/wps/portal /home/shop/shoes
/wps/portal /home/shop/shoes/!ut/p/04_SB8K8xLLM9MS...
WebSphere Portal v6
Syntax of Friendly-URLs
� Trivia
� If a URL-mapping prefix collides with a friendly name the URL-mapping takes precedence
� Friendly-URLs are readable but potentially longer than rich-URLs
� Friendly-Name
� A path segment that is associated with a content node (page)
� The friendly-path is generated based on the content topology
� Suffix
� The navigational state is encoded as a suffix
�Because the friendly path itself does not contain enough information to maintain the navigational state!
� There exist APIs to produce URLs that contain the friendly-path only (used for entry-point URLs)
scheme://host:port/ctx/vpname (/frdly-name)* (/!ut/p/...)?
friendly-path
WebSphere Portal v6
Recommendations
� Use friendly-URLs if ...
�... your application requires to contain a human-readable identifier�... you use security proxies that peform access control based on URL prefix matching
� Keep in mind that ...
�... URLs become longer�... there is a performance impact in computing friendly URLs for page changes (because delta encoding is no longer possible)
WebSphere Portal v6
Generation and Assignment of Friendly-URLsThe Page-Properties Portlet
� Friendly-names can be managed via the admin UI, XMLAccess or Scripting
� In XMLAccess and Scripting they appear as page metadata
� Friendly-paths are generated automatically without the need for special APIs
� To generate URLs that contain the friendly-path only
1. Pass keepNavState=„false“ to the URL-tags
2. Use the com.ibm.portal.resolver.friendly.service.FriendlySelectionService API
WebSphere Portal v6
Different Types of URLs
� Render-URLs and Action-URLs
� Rich-URLs and Delta-URLs
� Virtual-Portal URLs
� URL-Mappings
� Friendly-URLs
� Piece-of-Content URLs
WebSphere Portal v6
Intermezzo: URLs, URIs and Resources
� So far WebSphere Portal URLs specify the exact location of resources
�the navigational state specifies the exact portal page and the status of the UI widgets (portlets)
� The same content (document) e.g. might be located on different pages and is therefore addressable via different URLs
� For some usecases however it is desirable to address content independent of its location
� URL
�Uniform Resource Locator
� URI
�Uniform Resource Identifier
� Resource
�The piece of content that is identified by a URI or located by a URL
client
URL
portal (display) Actual content (displayed)
Content ID != URL
WebSphere Portal v6
Piece-of-Content (POC) URIs
� Content can be identified via a unique ID
�� it has a URI
� The URI that identifies the content is typically not the same as the URL that displays this content
�there may be many URLs that display the same URI�the URL can be used as the URI if there is only one possible content location
� POC Framework (WP 6.01)
� Provides mechanisms to find a „view“ of a piece-of-content in a given portal context
�� converts from URI to URL
� Allows custom code to define their own content schemes and participate in the „view“ resolution
WebSphere Portal v6
POC-URI Resolution
� Resolution out-of-context
� Client requests a view of a URI
�Without portal context, e.g. by clicking an e-mail link
� Resolution in-context
� Client clicks on a link that points to a URI during interaction with the portal
�E.g. by clicking on a search result entry
clientPOCservlet
POCresolver
Portalservlet
PortalRendering
URIURI
navstate(URL)
URL
URL
navstate
markup
markup
findlocation
clientPortalservlet
POCresolver
markup
markup
PortalRendering
URLURI + navstate
findlocation
navstate‘
navstate‘
WebSphere Portal v6
Syntax of POC-URLs
� Trivia
� The POC framework can also be used to directly access the content as a data stream (vs. its view, see documentation)
� POC Servlet
� The POC servlet is the well-defined entry point into the resolution framework
� There exist a protected and an unprotected servlet (poc vs. mypoc)
� The URI is passed as a QueryParameter
�this syntax can be used with GET-FORMs�Additional query parameters can be added (see documentation)
� The POC servlet computes the navigational state that represents the view of the URI and redirects
scheme://host:port /[my]poc /vpname ?uri=<URI>(&<k>=<v>)*
Resolutionservlet
Identificationof the piece-of-content
WebSphere Portal v6
Generation of POC-URLs
� POC-URLs can be generated via the com.ibm.portal.resolver.service.PocService API
� Via a TAG API in the http://www.ibm.com/xmlns/prod/websphere/portal/v6.0.1/resolver namespace
� <resolver:resolvedURL/>
<%@ taglib uri="http://www.ibm.com/xmlns/prod/websphere/portal/v6.0.1/resolver" prefix="resolver" %>
<form method="GET" action=" <resolver:resolvedURL/>" >
Enter POC-URI:
<input type="text" name="uri" value="">
<input type="submit" name="submit" value=„Display">
</form>Res
olve
d-U
RL
in a
JS
P
WebSphere Portal v6
Recommendations
� Use POC-URLs if you want to link to content and not to explicit navigational state (e.g. search results, documents, etc.)
� POC-URLs can be encoded very efficiently, because the resolution process only happens when a link is clicked (late binding)
� Extend the POC framework by adding custom URI schemes
WebSphere Portal v6
Addendum: StateHandling and Client-Side-Aggregation
� In the client-side aggregation the navigational state is managed inside the DOM
� Some interactions still require a server roundtrip � the navigational state needs to be encoded as a URL
� URLs in server side generated markup need to be decoded by the client to update the navigational state
� There exists a public REST service that allows to encode and decode navigational state to and from URLs
WebSphere Portal v6
References
� http://www.ibm.com/developerworks/websphere/library/techarticles/0603_behl/0603_behl.html
� http://www.ibm.com/developerworks/websphere/library/techarticles/0612_behl/0612_behl.html
� http://www.w3.org/TR/uri-clarification
� http://www.w3.org/TR/webarch/
� http://www.w3.org/2001/tag/doc/whenToUseGet.html
� http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/index.jsp?topic=/com.ibm.wp.ent.doc/wps/dgn_ptltld.html
� http://www.ietf.org/rfc/rfc1738.txt