3 Replies Latest reply on Aug 7, 2006 7:46 PM by antoine_h

    Page-level parameters for requests: how to create bookmarkab


      JBossAS 4.0.4.GA
      JBossPortal 2.2.1-SP3

      The only way to pass a parameter to a portlet AND allow that portlet to render first (before other portlets on that page), is by using action urls. These urls force a reload and are therefore useless for "nice" url's.

      Since you can do a ctrl:cmd=render&ctrl:page=Portal.Page, couldn't parameters to that page be delegated to each window on that page?

      My case is one where multiple portlets on a single page require the same data based on a parameter (read-only), such as an id for a person, and this page needs to be bookmarkable.

      * With action urls everything except bookmarking works
      * With render urls bookmarking works, but ordering is undefined, so the portlet getting the parameter works, but it cannot share that data with other portlets because it might not be called first
      * Going out-of-spec by casting the render request to a jboss-specific request could have worked if the class hierarchy exposed the http servlet request which is stored as a protected variable, and then have all portlets get the parameters

      What are other people doing with JBossPortal to address these issues?

      How do you create something like:


      ....as a dynamic page that doesn't redirect.

      (And no: using a page with a single portlet doesn't quite cut it)

        • 1. Re: Page-level parameters for requests: how to create bookma

          The format of URLs has been improved toward that direction in 2.4.

          The format or an action or render URL is like /portal/portal/default/mypage/mywindow?a=b&c=d&...

          Where /portal/portal is a prefix that depends on your settings, /default/mypage/mywindow is the path to the portlet window targetted by the request and the list of parameters contains either render parameters or action parameters.

          A special parameter is also inserted in the list of parameters in order to make the portal distinguish between action and render.

          We also can render page using an URL that points to a page. However any parameter to a page is discarded and never propagated to any portlet.

          • 2. Re: Page-level parameters for requests: how to create bookma

            Yes, we ended up doing something like:

            * Introduce a command servlet
            * Rewrite rules changing the "nice" url to one with parameters that the servlet can parse (including which portal page to use)
            * Do checking and logic in the command servlet
            * Use HTTP getting directly inside the command servlet to the correct render url, targetting ctrl:page=Portal.Page with additional parameters
            * Introduce a portlet superclass that uses Policy to obtain the actual servlet request, and put that on the session so that each portlet on that page can access the information

            Not the best of solutions, but no JBoss-specific classes used, and objective reached.

            • 3. Re: Page-level parameters for requests: how to create bookma


              I am thinking of another way, that does not deal do much with servlet and deep mechanism.

              if I understand well your will, you want to get some parameters before the rendering process has started, and share them with all the portlets.

              For "intercepting" these parameters, you can build your own CommandFactories, derived from the one provided with jbp.
              They filters the parameters that you want to share and send them, through a message store, to all the portlets that will need it.

              as a message store and sharing parameter implementation, you can use the M. Osmond implementation.
              see this post : http://jboss.org/index.html?module=bb&op=viewtopic&t=87442
              (this feature of sharing parameters seems also to be in preparation for JSR-168 2.0 and in jbp 2.4 with the access to the portal objects nodes).

              The thing is to use the messaging implementation from inside a command factory, to send messages from there instead of from the portlets.
              The message must be stored with a reference to a "Session ID".

              In a Portlet, it uses the PortletSessionID to send the message.
              In the CommandFactory, the message may be sent in the same way, but with providing the session id (coming from the httpSessionId).
              There's some work to do to adapt the messaging class, so it can do a send, with other parameters than the PortletRequest.
              In the commandFactory, it seem you can retrieve the SessionID from the Invocation => Request => HttpRequest (to check really, I have just had a quick look at it).

              To check : the portlet session Id must be the same as the http session id (which should be, but I am not sure the JSR ask for this... and quite sure not...)

              To put your command factories in place of the one provided by jbp, you can use the service methods to unregister the ones and register yours in place off, or, more simple, replace the jboss-service.xml with yours, that say to use your classes instead of the one defined.

              a lot of work, but it seems ok to work.
              I would set first the Messaging Portlet implementation, and check that the session identification for messages can be the same from the one that you get from the command factory, so you can send the message from there.
              then see the command factory side.
              after, it should be easy. lot of setting, testing and tuning.

              the advantage is not to deal with servlet stuff that much, but more "after", when the portal processes the request".
              and by using the Messaging implementation, you can use it for other needs. It provide by itself a good way to manage this sharing of parameters issue, and good ideas on how to do it (multiple same portlet on one page, etc...).

              hope it may help.