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 |
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&wsrp-windowState=normal&wsrp-mode=view&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 |
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&wsrp-windowState=normal&wsrp-mode=view&wsrp-navigationalState=oxf.path%3d/tutorial-hello1/wsrp_rewrite" > f:url-norewrite="true">Test</a> > 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> 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 |
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 |
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 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 |
Free forum by Nabble | Edit this page |