URL Mapping & Friendly URLs Leue 20090303

© 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


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!

e-mail

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


<%@ 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>


�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


<%@ 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





� URL-Mappings

� Friendly-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





� URL-Mappings

� Friendly-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





� URL-Mappings

� Friendly-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





� URL-Mappings

� Friendly-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





� URL-Mappings

� Friendly-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

Documents

URL Mapping & Friendly URLs Leue 20090303