Portlets and oxf:request

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Portlets and oxf:request

Ray Auge
Hello Erik,

I'm wondering if I might suggest...

1. making oxf:request portlet-aware by adding the PortletMode and the
WindowState when, say

 (externalContext.getNativeRequest() instanceof PortletRequest)

or

2. creating an "oxf:portlet-request" which includes current plus the
extra portlet state info.

By doing so, you can alter the pipeline path, obviously. Plus you
suddenly have access to unlimited portlet modes without having to alter
the current implementation of the portlet classes.

Also, I'm wondering if there is, currently, a way to define portlet
urls/submissions, which include the desired portlet mode and window
state.

Ray




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Portlets and oxf:request

Erik Bruchez
Administrator
Raymond,

 > Hello Erik,
 >
 > I'm wondering if I might suggest...
 >
 > 1. making oxf:request portlet-aware by adding the PortletMode and the
 > WindowState when, say
 >
 >  (externalContext.getNativeRequest() instanceof PortletRequest)
 >
 > or
 >
 > 2. creating an "oxf:portlet-request" which includes current plus the
 > extra portlet state info.

Good idea. I updated oxf:request to produce <window-state> and
<portlet-mode> element when run in a portlet.

 > By doing so, you can alter the pipeline path, obviously. Plus you
 > suddenly have access to unlimited portlet modes without having to
 > alter the current implementation of the portlet classes.
 >
 > Also, I'm wondering if there is, currently, a way to define portlet
 > urls/submissions, which include the desired portlet mode and window
 > state.

Well, you can do this with a trick: "wsrp_rewrite" is a magic value
that the OPS portlet interprets. Something like this should work:

<a xmlns:f="http://orbeon.org/oxf/xml/formatting"
 
href="wsrp_rewrite?wsrp-urlType=render&amp;wsrp-windowState=normal&amp;wsrp-mode=view&amp;wsrp-navigationalState=oxf.path%3d/tutorial-hello1/wsrp_rewrite"
    f:url-norewrite="true">Test</a>

The different names and values in that string are defined by the WSRP
spec:

wsrp-urlType:           render | blockingAction | resource

When wsrp-urlType = resource:

wsrp-url:               URL of the resource

When wsrp-urlType = render | blockingAction:

wsrp-windowState:       window state you want to set
wsrp-mode:              portlet mode you want to set
wsrp-navigationalState: for OPS, use oxf.path%3d followed by path

f:url-norewrite="true" is needed so that OPS URL rewriting doesn't
kick in.

In the future, we should build this into the URL rewriting mechanism,
for example:

<a xmlns:f="http://orbeon.org/oxf/xml/formatting"
    href="/tutorial-hello1"
    f:window-state="normal"
    f:portlet-mode=""view>Test</a>

-Erik

--
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Portlets and oxf:request

Ray Auge
On Sat, 2006-06-03 at 23:29 +0200, Erik Bruchez wrote:

> Raymond,
>
>  > Hello Erik,
>  >
>  > I'm wondering if I might suggest...
>  >
>  > 1. making oxf:request portlet-aware by adding the PortletMode and the
>  > WindowState when, say
>  >
>  >  (externalContext.getNativeRequest() instanceof PortletRequest)
>  >
>  > or
>  >
>  > 2. creating an "oxf:portlet-request" which includes current plus the
>  > extra portlet state info.
>
> Good idea. I updated oxf:request to produce <window-state> and
> <portlet-mode> element when run in a portlet.
>
>  > By doing so, you can alter the pipeline path, obviously. Plus you
>  > suddenly have access to unlimited portlet modes without having to
>  > alter the current implementation of the portlet classes.
>  >
>  > Also, I'm wondering if there is, currently, a way to define portlet
>  > urls/submissions, which include the desired portlet mode and window
>  > state.
>
> Well, you can do this with a trick: "wsrp_rewrite" is a magic value
> that the OPS portlet interprets. Something like this should work:
>
> <a xmlns:f="http://orbeon.org/oxf/xml/formatting"
>  
> href="wsrp_rewrite?wsrp-urlType=render&amp;wsrp-windowState=normal&amp;wsrp-mode=view&amp;wsrp-navigationalState=oxf.path%3d/tutorial-hello1/wsrp_rewrite"
>     f:url-norewrite="true">Test</a>
>
This will work perfectly. I imagine that the "wsrp-navigationalState"
maps to the path-info from page-flow, correct?

> The different names and values in that string are defined by the WSRP
> spec:
>
> wsrp-urlType:           render | blockingAction | resource
>
> When wsrp-urlType = resource:
>
> wsrp-url:               URL of the resource
>
> When wsrp-urlType = render | blockingAction:
>
> wsrp-windowState:       window state you want to set
> wsrp-mode:              portlet mode you want to set
> wsrp-navigationalState: for OPS, use oxf.path%3d followed by path
>
> f:url-norewrite="true" is needed so that OPS URL rewriting doesn't
> kick in.
>
> In the future, we should build this into the URL rewriting mechanism,
> for example:
>
> <a xmlns:f="http://orbeon.org/oxf/xml/formatting"
>     href="/tutorial-hello1"
>     f:window-state="normal"
>     f:portlet-mode=""view>Test</a>
This is exactly what I was thinking. Perhaps you should consider
including the url type (action/render) and the possibility of including
parameters to the url, "à là" portlet taglib.

<a xmlns:f="http://orbeon.org/oxf/xml/formatting"
    href="/tutorial-hello1"
    f:window-state="normal"
    f:portlet-mode="view"

    f:url-type="[render|action]"  #a little more control

    f:secure="[true|false]"       #again, a little more control

    f:portlet-name="portlet-name" #indicates the url is to be targeted
                                  #at portlet with id "portlet-name",
                                  #default is to target itself,
                                  #obviously the id must be
                                  #known to the developer
    >
        <f:param name="p1" value="v1"/> #these would add the possibility
        <f:param name="p2" value="v2"/> #to target none OPS portlets
        ...                             #and still pass parameters
        <f:param name="pN" value="vN"/>
        Test
</a>

The extra features add the possibility of performing a form of
inter-portlet communication, navigation between portlets, and
communication with none OPS portlets (believe me this will come up more
and more as OPS becomes visible in this space).

Ray

> -Erik
>
> plain text document attachment (message-footer.txt)
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Portlets and oxf:request

Erik Bruchez
Administrator
Raymond Auge wrote:

 > This will work perfectly. I imagine that the
 > "wsrp-navigationalState" maps to the path-info from page-flow,
 > correct?

Not directly, but it contains a parameter called oxf.path which plays
this role, yes. This is because JSR-168 portlets do not know anything
about the idea of "paths" as we are used to them with HTTP and
servlets. So the OPS Portlet create in the navigational state this
oxf.path parameter which plays this role.

 >> <a xmlns:f="http://orbeon.org/oxf/xml/formatting"
 >>     href="/tutorial-hello1"
 >>     f:window-state="normal"
 >>     f:portlet-mode=""view>Test</a>
 >
 > This is exactly what I was thinking. Perhaps you should consider
 > including the url type (action/render)

You can already use f:url-type for this purpose on <a>.

 > and the possibility of including parameters to the url, "à là"
 > portlet taglib.
 >
 > <a xmlns:f="http://orbeon.org/oxf/xml/formatting"
 >     href="/tutorial-hello1"
 >     f:window-state="normal"
 >     f:portlet-mode="view"
 >
 >     f:url-type="[render|action]"  #a little more control
 >
 >     f:secure="[true|false]"       #again, a little more control
 >
 >     f:portlet-name="portlet-name" #indicates the url is to be targeted
 >                                   #at portlet with id "portlet-name",
 >                                   #default is to target itself,
 >                                   #obviously the id must be
 >                                   #known to the developer
 >     >
 > <f:param name="p1" value="v1"/> #these would add the possibility
 > <f:param name="p2" value="v2"/> #to target none OPS portlets
 >         ...                             #and still pass parameters
 > <f:param name="pN" value="vN"/>
 > Test
 > </a>
 >
 > The extra features add the possibility of performing a form of
 > inter-portlet communication, navigation between portlets, and
 > communication with none OPS portlets (believe me this will come up
 > more and more as OPS becomes visible in this space).

Here I have a question: how to you implement targeting another
portlet? As far as I know, JSR-168 has no provision for this.

-Erik

--
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Portlets and oxf:request

Ray Auge
On Sat, 2006-06-10 at 16:45 +0100, Erik Bruchez wrote:

> Raymond Auge wrote:
>
>  > This will work perfectly. I imagine that the
>  > "wsrp-navigationalState" maps to the path-info from page-flow,
>  > correct?
>
> Not directly, but it contains a parameter called oxf.path which plays
> this role, yes. This is because JSR-168 portlets do not know anything
> about the idea of "paths" as we are used to them with HTTP and
> servlets. So the OPS Portlet create in the navigational state this
> oxf.path parameter which plays this role.
>
>  >> <a xmlns:f="http://orbeon.org/oxf/xml/formatting"
>  >>     href="/tutorial-hello1"
>  >>     f:window-state="normal"
>  >>     f:portlet-mode=""view>Test</a>
>  >
>  > This is exactly what I was thinking. Perhaps you should consider
>  > including the url type (action/render)
>
> You can already use f:url-type for this purpose on <a>.
>
>  > and the possibility of including parameters to the url, "à là"
>  > portlet taglib.
>  >
>  > <a xmlns:f="http://orbeon.org/oxf/xml/formatting"
>  >     href="/tutorial-hello1"
>  >     f:window-state="normal"
>  >     f:portlet-mode="view"
>  >
>  >     f:url-type="[render|action]"  #a little more control
>  >
>  >     f:secure="[true|false]"       #again, a little more control
>  >
>  >     f:portlet-name="portlet-name" #indicates the url is to be targeted
>  >                                   #at portlet with id "portlet-name",
>  >                                   #default is to target itself,
>  >                                   #obviously the id must be
>  >                                   #known to the developer
>  >     >
>  > <f:param name="p1" value="v1"/> #these would add the possibility
>  > <f:param name="p2" value="v2"/> #to target none OPS portlets
>  >         ...                             #and still pass parameters
>  > <f:param name="pN" value="vN"/>
>  > Test
>  > </a>
>  >
>  > The extra features add the possibility of performing a form of
>  > inter-portlet communication, navigation between portlets, and
>  > communication with none OPS portlets (believe me this will come up
>  > more and more as OPS becomes visible in this space).
>
> Here I have a question: how to you implement targeting another
> portlet? As far as I know, JSR-168 has no provision for this.
>
> -Erik
You know? You got me on this one.

I was thinking of this because of Liferay's implementation which added
this feature as an extension. My mistake. As a note for the future, I
believe this feature will likely be included in v2.0 of the portlet
spec. It's basically a way of passing in the portletId as opposed to
using the default (obtain it from the current context).

You can disregard it.

Ray




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws