Skip to Content

If you’ve ever developed any custom portal components you might have wondered where all that extra HTML/CSS/JavaScript comes from that surrounds what you generate in our own code. Over the years I have often wondered if there was a way to tell the Portal Runtime to just give me back what I added to the HTTP response body and not all that extra stuff 😀 .

Recently I came across a way to do this, sort of by accident whilst looking into how some of the new Portal on Device features worked and speaking with Dong Pan from SAP. I looked around but didn’t find much in the way of documentation on this, so I wanted to at least start off by sharing what I could.

What I’d like to do in this blog is show you what I mean in more detail and also explain why this is a useful feature and one that is used in Portal on Device. So by way of example I have written a very simple “Hello World” portal component that just writes out that age old text to the response body. I want to compare the markup that is returned when I call this component in the “normal” way vs. what is generated when called with the prtrw URL.

Here is the simple code:

/wp-content/uploads/2012/05/code_101379.png

Well I won’t be winning any awards for that 😆 … but bear with me here. I deployed this to my 7.3 Portal and created an iView in the PCD. When you run this component by calling the following URL:

http://<server>:<port>/irj/servlet/prt/portal/prtroot/pcd!3aportal_content!2fplaut!2fscnHelloWorld

you get this back:

/wp-content/uploads/2012/05/portal_rendered_101380.png

and here is the source you can see in the browser if you view the source (quite a lot more stuff then I added):

/wp-content/uploads/2012/05/portal_101388.png

Now for the interesting bit… if I call the same component but replace the /irj/servlet/prt/portal/prtroot/ in the URL… with /irj/servlet/prt/prtrw/prtroot… the output is significantly different:

http://<server>:<port>/irj/servlet/prt/prtrw/prtroot/pcd!3aportal_content!2fplaut!2fscnHelloWorld

/wp-content/uploads/2012/05/prtrw_rendered_101389.png

And this time you get this when you view the source:

/wp-content/uploads/2012/05/prtrw_101396.png

So when you use the prtrw in the URL instead of portal, this apparently tells the Portal Runitme to bypass all the so called document hooks and avoids all the extra HTML, CSS and JavaScript that gets added by default.

So now you might be asking…So why is this useful???… well one reason is that if you wanted to write a Portal Component that produced a JSON or XML or oData response you don’t want all that other markup getting in the way. This was the use case I saw in the Portal on Device example – Portal Components were used to generate JSON responses and were being called from the client using JQuery AJAX calls.

Anyway I hope you find this interesting. Perhaps you have come across this little trick before? I noticed in my research that Visual Composer seems to use it too, but mostly it seems to be a well kept secret 😯 . Thanks for taking the time to read this post. Let me know what you think below.

To report this post you need to login first.

12 Comments

You must be Logged on to comment or reply to a post.

  1. Michael Nicholls

    Hi Simon

    Interesting, but my standard way to return raw output is to use something like:

    protected void doOnNodeReady(

    IPortalComponentRequest request,

    IEvent event) {

    HttpServletResponse response = request.getServletResponse(true);

    response.setContentType(“text/html”);

    response.setHeader(“Content-disposition”, “filename=\”test.htm\””)

    try {

      java.io.PrintWriter out = response.getWriter();

      response.setContentType(“text/html; charset=UTF-8”);

            out.print(“Hello world”);

      out.close();

    } catch (Exception e) {

      e.printStackTrace();

    }

    }

    and an empty

    public void doContent(IPortalComponentRequest request, IPortalComponentResponse response)

        {

        }

    That way there is no mucking around with URLs etc

    (0) 
    1. Simon Kemp Post author

      Thanks for sharing Michael, does that method also avoid all the document hooks? There is probably some subtle difference between the two methods, but good to know that there are (as usual) more than one way to achieve the same result.

      (0) 
      1. Michael Nicholls

        Possibly a PRT internals person would know the difference! I just know that when I want to return a plain response I need to use doOnNodeReady…

        (0) 
      2. Tobias Hofmann

        On 7.0x this works as well:

        public void doContent(IPortalComponentRequest request, IPortalComponentResponse response) {

          try {

            HttpServletResponse servletResponse = request.getServletResponse(true);

            PrintWriter out = servletResponse.getWriter();

            out.write(“<h1>Hello World</h1>”);

          catch (IOException e1) {}

        }

        The trick is to do the request.getServletResponse(true). This gives full control over the output.

        (0) 
          1. Tobias Hofmann

            I guess it also works on 7.3 systems, but as I do not have a 7.3 system around to test it, I can only say that it works for 7.0x 🙁

            (0) 
    1. Simon Kemp Post author

      Hi Tom, thanks for your comment. Yes perhaps you are right I am not that familiar with how NWBC integrates portal content.

      (0) 
  2. Felipe Forero Guzman

    Very well!

    Now that I can call a portal component by its url, the problem now would be getting access to the component with the guest user from a client app.

    Or some how the portal component now should be public ?

    (0) 
    1. Simon Kemp Post author

      Hi Felipe,

      You can of course access a portal component anonymously (without needing to login), if you set the iView property “Authentication Scheme” to “anonymous” and also set the permission on the iView to allow Guest to have “End User” access (do this via the permissions of the iView).

      Doing both these things will give you anonymous access directly via the URL.

      Thanks

      Simon

      (0) 
      1. Felipe Forero Guzman

        Hello again Simon and thanks for answering, I don’t usually hope for a quick answer!

        This is what is happening:

        I have no problem accessing the url through the web browser, I get a clean “hello word”. But when a access the url through an URL java object within a “public void main” program, I get a access denied for the guest user.

        But why, what is the diference, isn’t the same thing ?

        At this point, should be necessary to make an iView and set the propperties you are saying ?

        <edit>

        Hello, I had not realized that when I use the browser the portal also asks me for authentication. And this is why I need an  URL iView! Thanks Simon.

        (0) 

Leave a Reply