On Aug 26, 2004, at 8:03 AM, Rapha�l Luta wrote:
True, that is why we have a configurable navigational state component with currently 2 implementationsAte Douma wrote: > <snip>A Jetspeed PortalURL is build up out of 5 parts:>
[<baseURL>/<basePath>][/GlobalNavigation][/ControlParameters][? RequestParameters][#LocalNavigation] The [baseURL/basePath] defines the access point to the portal like:
[<http://localhost>/<jetspeed/portal>]
The [/GlobalNavigation] defines site navigation to folders and pages like:
[/], or [/default-page] or [/default-page.psml] for the default page
or [/Administrative/pam]
or [/rootfolder/subfolder/page]
etc.
The [/ControlParameters] define statefull portlet specific parameters like for window mode, portlet mode and portlet request parameters.
These parameters are encoded in two different ways.
Non-portlet request parameters:
<prefix><type>_<portletWindowId>/<value>
Portlet request parameters <prefix><type>_<portletWindowId>_<parameterName>/ <parameterCount>_<parameterValue1>[[_<parameterValue<x>]...]
> The control parameters prefix and type keys are all externally definable
> (in spring assembly jetspeed-spring.xml)
>
AFAIK, the JSR168 does not mandate that these parameters be included in the URL, you could keep them only in the session and never send them back to the browser.
The only disadvantage I see of doing this is that it becomes impossible for the user to bookmark a portal page in a non-default state.
I personnally would rather like to have clean simple URLs and not be able to
boolmark pages in non-default states than having extremely long and unnatural
URLs sent to the user.
The other implementation uses Pluto URLs, which are much longer than the Jetspeed URLs since they encode all current and previous states
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
