portletspec3
  1. portletspec3
  2. PORTLETSPEC3-36

Ajax: Remove ability for portlets to provide resources

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Component/s: Stateful Ajax Support
    • Labels:
      None

      Description

      Reference: Ajax Proposal 2b

      The current proposal allows both the portal and individual portlets to contribute resources for sharing with other portlets.

      There is concern that this may lead to improper behavior if different portlets use the same name for different resources. For example, portlet A might provide a certain library at a certain version level. Portlet B might provide that same library at the same version level, but in reality, portlet B's library might be slightly modified as compared to that from portlet A (a fix or debug code might be added by one portlet but not the other, etc).

      This could potentially lead to a situation where the behavior of the portlets on the page depends on the order in which the portlets appear on the page, or on the algorithm used by the portal for selecting resources when more than one resource of the same name is available. Bugs resulting from such a situation could be very hard to find.

      It might be safer to allow portlets to only specify the resources they depend on. The actual resources themselves would always be provided by the portal - individual portlets would not be able to contribute resources for consumption by other portlets.

      The manner in which resources are configured in the portal would remain unspecified and implementation-specific.

        Activity

        Hide
        Neil Griffin added a comment -

        Portlets developed against the existing Portlet 2.0 standard can contribute resources to the rendered page via the following syntax:

        @Override
        public void doView(RenderRequest request, RenderResponse response) {
            renderResponse.setProperty(MimeResponse.MARKUP_HEAD_ELEMENT, element);
        }
        

        See: http://portals.apache.org/pluto/portlet-2.0-apidocs/javax/portlet/MimeResponse.html#MARKUP_HEAD_ELEMENT

        Resources that are contributed in this manner end up in the <head>...</head> section of the rendered portal page by default, and are by nature "shared" with other portlets.

        Because of this, it seems like it would be OK to permit portlets to serve up their own resources using a feature similar to the JSF ResourceHandler. It wouldn't introduce any type of potentially troublesome behavior that doesn't already exist in Portlet 2.0.

        Show
        Neil Griffin added a comment - Portlets developed against the existing Portlet 2.0 standard can contribute resources to the rendered page via the following syntax: @Override public void doView(RenderRequest request, RenderResponse response) { renderResponse.setProperty(MimeResponse.MARKUP_HEAD_ELEMENT, element); } See: http://portals.apache.org/pluto/portlet-2.0-apidocs/javax/portlet/MimeResponse.html#MARKUP_HEAD_ELEMENT Resources that are contributed in this manner end up in the <head>...</head> section of the rendered portal page by default, and are by nature "shared" with other portlets. Because of this, it seems like it would be OK to permit portlets to serve up their own resources using a feature similar to the JSF ResourceHandler . It wouldn't introduce any type of potentially troublesome behavior that doesn't already exist in Portlet 2.0.
        Hide
        kito75 added a comment -

        I agree with Neil – some sort of registration mechanism makes sense. This does mean, however, that resources referenced manually without registration should be disallowed.

        Show
        kito75 added a comment - I agree with Neil – some sort of registration mechanism makes sense. This does mean, however, that resources referenced manually without registration should be disallowed.

          People

          • Assignee:
            Unassigned
            Reporter:
            msnicklous
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: