DisplayTag
  1. DisplayTag
  2. DISPL-344

Export failure running as Liferay portlet

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.1
    • Fix Version/s: TBD
    • Component/s: Export
    • Labels:
      None
    • Application server:
      Liferay 4.0.0rc2 and Tomcat 5.5.16

      Description

      When click on any of the Export options, the content of the portlet is replaced with the exported data.

      If do not add the "displaytag extensions" for JSR 168 portlet support, the export feature works correctly.

      I consider this a blocker because without the portlet extensions the "pagesize" table attribute has unacceptable behavior (so I have to choose which feature I prefer to enable).

        Activity

        Hide
        Eric Dalquist added a comment -
        Here is a high level overview of what I was thinking as far as an external servlet goes, with some background. If any of it needs clarification feel free to ask.


        The servlet spec states that a portlet and a servlet in the same web-application share a session object. Data put into the session in the application scope by a portlet should be readily readable by a servlet in the same web-app being accessed by the same user. Data put into the session in the portlet scope by the portlet will be accessible but will likely have a name-spaced name, this makes portlet scoped session attributes hard to use.

        The down side of a user accessing this external servlet is you don't have any information about the user accessing the servlet like you do inside of the portlet. This is why the session sharing is important, the portlet will need to put some useful bit of data in the session so the servlet has some context for what is expected to do.


        With those two notes the approach I would take follows (at a very high level).
        The export URL rendered by displaytag points to this servlet that is mapped in the portlet's web application.
        Every time displaytag renders it uses some standard portlet session attribute (probably with some configurable key in the name so multiple tables can be on one page) to put a bit of requisite info for the servlet into the session.
        The URL to the export servlet includes this configurable key so the servlet knows which session attribute to get its requisite export info from.
        When the user clicks on the link the servlet looks in the session with the specified key for the info it needs to export the data.


        This will slightly pollute the session since there is no way for the portlet to know when the data can be removed from the session and the data must always be in the session since the portlet won't know when the user clicks on the export link.

        When I was doing the work to get display tag JSR-168 compliant I didn't look at the export code at all since that wasn't one of my needs. This high level overview may need some refining to work with the way displaytag does exports. If you need more information please feel free to ask.
        Show
        Eric Dalquist added a comment - Here is a high level overview of what I was thinking as far as an external servlet goes, with some background. If any of it needs clarification feel free to ask. The servlet spec states that a portlet and a servlet in the same web-application share a session object. Data put into the session in the application scope by a portlet should be readily readable by a servlet in the same web-app being accessed by the same user. Data put into the session in the portlet scope by the portlet will be accessible but will likely have a name-spaced name, this makes portlet scoped session attributes hard to use. The down side of a user accessing this external servlet is you don't have any information about the user accessing the servlet like you do inside of the portlet. This is why the session sharing is important, the portlet will need to put some useful bit of data in the session so the servlet has some context for what is expected to do. With those two notes the approach I would take follows (at a very high level). The export URL rendered by displaytag points to this servlet that is mapped in the portlet's web application. Every time displaytag renders it uses some standard portlet session attribute (probably with some configurable key in the name so multiple tables can be on one page) to put a bit of requisite info for the servlet into the session. The URL to the export servlet includes this configurable key so the servlet knows which session attribute to get its requisite export info from. When the user clicks on the link the servlet looks in the session with the specified key for the info it needs to export the data. This will slightly pollute the session since there is no way for the portlet to know when the data can be removed from the session and the data must always be in the session since the portlet won't know when the user clicks on the export link. When I was doing the work to get display tag JSR-168 compliant I didn't look at the export code at all since that wasn't one of my needs. This high level overview may need some refining to work with the way displaytag does exports. If you need more information please feel free to ask.
        Hide
        Eric Dalquist added a comment -
        Andy,

        That is an interesting suggestion. One issue is according to the portlet spec you don't know what format the URLs will end up being. It is perfectly valid to add twenty parameters to the URL and it to look like http://my.portal.com/portal/12712367AF23 where the end bit is just a key to some internal map the portal keeps.

        I'm not saying it isn't a valid solution but it will not likely work on all portals because of the URL format restrictions.
        Show
        Eric Dalquist added a comment - Andy, That is an interesting suggestion. One issue is according to the portlet spec you don't know what format the URLs will end up being. It is perfectly valid to add twenty parameters to the URL and it to look like http://my.portal.com/portal/12712367AF23 where the end bit is just a key to some internal map the portal keeps. I'm not saying it isn't a valid solution but it will not likely work on all portals because of the URL format restrictions.
        Hide
        Kelly Graves added a comment -
        Eric,

        Well I ran into some problems with Vignette. It seems that when placing data into the session from a portlet (application scope) they actually use undocumented wrapper classes for the attributes stored making it impossible for me to pull this data out from a web-app servlet. This obviously is not adhering to the spec so I am going to open a ticket with Vignette.

        What I am doing in the meantime...

        - Created a web-app servlet that re-queries for the same data set as portlet. New servlet forwards to a new JSP that includes the same display:table tag as was used in the original portlet jsp (but wouldn't necessarily have to.)
        - In the html for the original portlet JSP, i include custom export links for the user that pass the necessary request parameters to cause the new servlet+jsp to respond directly with the pdf or excel version.
        - Set up the ResponseOverrideFilter for the new servlet.
        - Had to modify PortletRequestHelperFactory.java - Since when processing directly from the web-app, PortletRequestHelper is expecting to find the javax.portlet attributes, which are not present. So I had to put in a check in the Factory to fall back to the regular RequestHelper in this case. Can't set the Factory property from within the tag, so can't switch it based on the context I'm in.

        Things are working fine at present.

        I'll keep you posted...

        Kelly
        Show
        Kelly Graves added a comment - Eric, Well I ran into some problems with Vignette. It seems that when placing data into the session from a portlet (application scope) they actually use undocumented wrapper classes for the attributes stored making it impossible for me to pull this data out from a web-app servlet. This obviously is not adhering to the spec so I am going to open a ticket with Vignette. What I am doing in the meantime... - Created a web-app servlet that re-queries for the same data set as portlet. New servlet forwards to a new JSP that includes the same display:table tag as was used in the original portlet jsp (but wouldn't necessarily have to.) - In the html for the original portlet JSP, i include custom export links for the user that pass the necessary request parameters to cause the new servlet+jsp to respond directly with the pdf or excel version. - Set up the ResponseOverrideFilter for the new servlet. - Had to modify PortletRequestHelperFactory.java - Since when processing directly from the web-app, PortletRequestHelper is expecting to find the javax.portlet attributes, which are not present. So I had to put in a check in the Factory to fall back to the regular RequestHelper in this case. Can't set the Factory property from within the tag, so can't switch it based on the context I'm in. Things are working fine at present. I'll keep you posted... Kelly
        Hide
        Abhay Nilakhe added a comment -
        Kelly,
            
        me too trying display tag export within JSR168 portlet with Vignette7.2.
        Can you please provide the solution?

        Many Thanks,
        Abhay Nilakhe
        Show
        Abhay Nilakhe added a comment - Kelly,      me too trying display tag export within JSR168 portlet with Vignette7.2. Can you please provide the solution? Many Thanks, Abhay Nilakhe
        Hide
        Narcis Paslaru added a comment -
        Hi,

        I need the export to work on WebSphere Portal with JSR-168 Struts portlets.
        The sorting and pagination works fine. Only the export doesn't work.
        There is the error about the filter :



        Exception: [.TableTag] Unable to reset response before returning exported data. You are not using an export filter. Be sure that no other jsp tags are used before display:table or refer to the displaytag documentation on how to configure the export filter (requires j2ee 1.3).



        Is there a solution to this ?
        Thanks,
        Narcis
        Show
        Narcis Paslaru added a comment - Hi, I need the export to work on WebSphere Portal with JSR-168 Struts portlets. The sorting and pagination works fine. Only the export doesn't work. There is the error about the filter : Exception: [.TableTag] Unable to reset response before returning exported data. You are not using an export filter. Be sure that no other jsp tags are used before display:table or refer to the displaytag documentation on how to configure the export filter (requires j2ee 1.3). Is there a solution to this ? Thanks, Narcis

          People

          • Reporter:
            Bill Joy
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: