Re: WSRP consumer rewriting vs. portlet API in WP5.1.x - Websphere

This is a discussion on Re: WSRP consumer rewriting vs. portlet API in WP5.1.x - Websphere ; The idea with the wsrp_rewrite statements is to delegate the responsibility for encoding the urls to the consumer thus giving access to pages, etc. that exist on the consumer...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Re: WSRP consumer rewriting vs. portlet API in WP5.1.x

  1. Re: WSRP consumer rewriting vs. portlet API in WP5.1.x

    The idea with the wsrp_rewrite statements is to delegate the responsibility for encoding the urls to the consumer thus giving access to pages, etc. that exist on the consumer

  2. Re: WSRP consumer rewriting vs. portlet API in WP5.1.x

    understood, but in the specification and in the portal documentation I do not see a way to tell the consumer to create a url to a page. The url types that can be created are all targeting something in the portlet being consumed, either render, resource, or something of that nature. As I can see right now there is no way to tell the consumer to rewrite into a url targeting a page in the consumer





    IBM Certified System Administrator -- WebSphere Portal V6.0, V5.1, V5.0

    IBM Certified Solution Developer -- WebSphere Portal V5.1, v6.0



    The postings on this site are my own and do not necessarily represent the positions, strategies, or opinions of IBM

  3. Re: WSRP consumer rewriting vs. portlet API in WP5.1.x

    I think my original post may not have been specific enough about the pages I wish to access. When I was talking about multiple pages, I meant within the same portlet, not necessarily different portal pages. (Although I would have also liked to able to specify going to different portal pages too)



    The main usecase I need to solve is, for instance, the first page of my remote portlet could be some kind of form submission which I would want to be submitted, with the same remote portlet then dealing with the submitted form and displaying some other UI on the same portal page.



    I thought that the WSRP specification says that this can be achieved using the wsrp-urlType=blockingAction within the wsrp_rewrite statement. (although I can't find any concrete examples of the usage under WP5.1)



    This certainly seems to be the case having done searches on other portal vendors inplementations of WSRP.



    What would be really useful if there was some examples and documentation of the use of wsrp_rewrite feature of WSRP under Websphere Portal.

  4. Re: WSRP consumer rewriting vs. portlet API in WP5.1.x

    ahh yes the blockingaction should work, at least from my reading of the spec., and you are right I see no documentation at all in the infocenter about this.



    Jim



    IBM Certified System Administrator -- WebSphere Portal V6.0, V5.1, V5.0

    IBM Certified Solution Developer -- WebSphere Portal V5.1, v6.0



    The postings on this site are my own and do not necessarily represent the positions, strategies, or opinions of IBM

  5. Re: WSRP consumer rewriting vs. portlet API in WP5.1.x

    Jim,



    Thanks for your responses.



    It seems like a common thing that anyone dealing with WSRP in the WebSphere Portal world would need, so I am surprised at the lack of official information.



    Do you (or anyone else) know if there are other avenues where I can get hold of the info I require (details of WebSphere Portal Server(preferably 5.1.x)s impl of wsrp_rewrite and how this maps to the portlet API tags (with examples))?



    Cheers



    Justin

  6. Re: WSRP consumer rewriting vs. portlet API in WP5.1.x

    Let me check with dev

    I will let you know

    Jim





    IBM Certified System Administrator -- WebSphere Portal V6.0, V5.1, V5.0

    IBM Certified Solution Developer -- WebSphere Portal V5.1, v6.0



    The postings on this site are my own and do not necessarily represent the positions, strategies, or opinions of IBM

  7. Re: WSRP consumer rewriting vs. portlet API in WP5.1.x

    I checked with the dev team and this is the response



    the generation of wsrp_rewrite expressions happens under the covers and should be transparent to the developer.

    There is no need for developers to generate handcrafted rewrite expressions in the markup, I would even strongly discourage that.

    There are things which portal adds to the rewrite urls regarding state management, namespacing, etc.

    Portlet programmer should just use the portlet API and the respective jsp tags to create portlet URLs.



    When you create and action URL, the WP URL generator creates a wsrp_rewrite expression with the urlType=blockingInteraction for that portlet if the portlet was called via WSRP.

    Creating a render URL, creates a wsrp render URL respectively.

    Encode URL creates a wsrp resource URL.



    The parameters you add to an URL are stored into the wsrp-navigationalState and the portlet recieves those back vie the PortletRequest. This is how the mentioned "pages scenario" should work. Each page should correspond to a navigational state and the portlet should render according to that state.

    Regarding form parameters: these become also available vie PortletRequest parameters if the URL was encoded as an action URL.



    Note that the wsrp protocol has no notion of "consumer" pages, thus a portlet can not create URLs that invoke/redirect the client to a different consumer portal page





    IBM Certified System Administrator -- WebSphere Portal V6.0, V5.1, V5.0

    IBM Certified Solution Developer -- WebSphere Portal V5.1, v6.0



    The postings on this site are my own and do not necessarily represent the positions, strategies, or opinions of IBM

  8. Re: WSRP consumer rewriting vs. portlet API in WP5.1.x

    Cheers for the digging Jim.



    I was having a problem originally because I had some links to other consumer pages within my jsp, having removed these, the action url works fine and I get all the form data + can move on to the next page.



    I will just have to specify these other links via externalised urls and all should be ok.



    Thanks



    Justin

+ Reply to Thread