Details

      Description

      Add methods to the BaseURL class to provide additional function.

      1) add a way to manage fragment identifiers in URLs in order to be able to create URLs such as:

      http://www.w3.org/TR/REC-html40/intro/intro.html#h-2.1.2

      void setFragmentIdentifier(String)
      String getFragmentIdentifier()

      2) add a method to create URLs that required the user to log in before they can access the URL

      void setProtected(Boolean)

        Activity

        Hide
        msnicklous added a comment -

        Here are my concrete proposals:

        1) for set authenticated

        void setAuthenticated(boolean authenticated)

        Indicates whether authentication is required for this URL.

        When the parameter is set to true, user authentication will be required when accessing the URL. A setting of false indicates that authentication will not be required.

        If authentication is not explicitly set on the URL through this method, the default will be true if PortletRequest.getAuthType() indicates that the current request is authenticated and false if the current request is not authenticated.

        Parameters:
        authenticated - true, if the URL requires authentication. false, if the URL does not require authentication.
        Since:
        3.0

        boolean getAuthenticated()

        Returns the authentication setting for the URL.

        Returns:
        true if the URL requires authentication
        Since:
        3.0

        2) for the fragment identifier

        void setFragmentIdentifier(String fragment)

        Sets a fragment identifier on the URL.

        The fragment identifier consists of additional information appended to the URL after a '#' character. A URL can have only a single fragment identifier. The fragment identifier may not contain the '#' character.

        The fragment identifier is often used to address a named anchor such as <a name="#fragmentIdentifier">, but it can also be used for other purposes such as to provide additional information for resource serving.

        The fragment identifier will not be namespaced. The portlet is responsible for performing any required namespacing.

        Any previously set fragment identifier will be replaced.

        Parameters:
        fragment - The fragment identifier to be added to the URL
        Throws:
        IllegalArgumentException - if the fragment identifier is null, the empty string (""), or contains the '#' character.
        Since:
        3.0

        String getFragmentIdentifier()

        Gets the fragment identifier set on the URL.

        Returns:
        The fragment identifier set on the URL, or null if no fragment identifier has been set.
        Since:
        3.0

        Show
        msnicklous added a comment - Here are my concrete proposals: 1) for set authenticated void setAuthenticated(boolean authenticated) Indicates whether authentication is required for this URL. When the parameter is set to true, user authentication will be required when accessing the URL. A setting of false indicates that authentication will not be required. If authentication is not explicitly set on the URL through this method, the default will be true if PortletRequest.getAuthType() indicates that the current request is authenticated and false if the current request is not authenticated. Parameters: authenticated - true, if the URL requires authentication. false, if the URL does not require authentication. Since: 3.0 boolean getAuthenticated() Returns the authentication setting for the URL. Returns: true if the URL requires authentication Since: 3.0 2) for the fragment identifier void setFragmentIdentifier(String fragment) Sets a fragment identifier on the URL. The fragment identifier consists of additional information appended to the URL after a '#' character. A URL can have only a single fragment identifier. The fragment identifier may not contain the '#' character. The fragment identifier is often used to address a named anchor such as <a name="#fragmentIdentifier">, but it can also be used for other purposes such as to provide additional information for resource serving. The fragment identifier will not be namespaced. The portlet is responsible for performing any required namespacing. Any previously set fragment identifier will be replaced. Parameters: fragment - The fragment identifier to be added to the URL Throws: IllegalArgumentException - if the fragment identifier is null, the empty string (""), or contains the '#' character. Since: 3.0 String getFragmentIdentifier() Gets the fragment identifier set on the URL. Returns: The fragment identifier set on the URL, or null if no fragment identifier has been set. Since: 3.0
        Hide
        msnicklous added a comment -

        Resolved by adding several methods to BaseURL:

        setAuthenticated
        getAuthenticated
        setFragmentIdentifier
        getFragmentIdentifier
        permitFragmentIdentifier
        fragmentIdentifierPermitted

        Handling the fragment identifier was more complicated than I initially anticipated. I ended up introducing two additional API methods that we hadn't discussed - I apologize for that. I should have thought more carefully before I committed. I should have posted the proposals in the issue in order to allow discussion and perhaps look for alternatives.

        Anyway, the background is that a portal can set the fragment identifier on portlet URLs (WebSphere does so in certain situations). That isn't wrong or non-compliant, since JSR286 doesn't mention fragment identifiers at all, and since the fragment identifier is never transported back to the server.

        The basic idea behind the latter four APIs in the list above is to allow the portal implementation to append a fragment identifier to a portlet URL if the portlet itself isn't using it. In addition, it should be possible for a portlet to explicitly request that absolutely no fragment identifier gets appended to a URL, even if the portlet itself is not using it.

        It seemed to best to implement both of the ideas of the getting / setting of the fragment identifier and the permitting / suppression of the fragment identifier by introducing the two pair of getter / setter methods - setFragmentIdentifier/getFragmentidentifier and permitFragmentIdentifier/fragmentIdentifierPermitted.

        I also updated the corresponding section in the spec - please see link.

        If there is need for discussion on this point, please reopen and we can discuss.

        Show
        msnicklous added a comment - Resolved by adding several methods to BaseURL: setAuthenticated getAuthenticated setFragmentIdentifier getFragmentIdentifier permitFragmentIdentifier fragmentIdentifierPermitted Handling the fragment identifier was more complicated than I initially anticipated. I ended up introducing two additional API methods that we hadn't discussed - I apologize for that. I should have thought more carefully before I committed. I should have posted the proposals in the issue in order to allow discussion and perhaps look for alternatives. Anyway, the background is that a portal can set the fragment identifier on portlet URLs (WebSphere does so in certain situations). That isn't wrong or non-compliant, since JSR286 doesn't mention fragment identifiers at all, and since the fragment identifier is never transported back to the server. The basic idea behind the latter four APIs in the list above is to allow the portal implementation to append a fragment identifier to a portlet URL if the portlet itself isn't using it. In addition, it should be possible for a portlet to explicitly request that absolutely no fragment identifier gets appended to a URL, even if the portlet itself is not using it. It seemed to best to implement both of the ideas of the getting / setting of the fragment identifier and the permitting / suppression of the fragment identifier by introducing the two pair of getter / setter methods - setFragmentIdentifier/getFragmentidentifier and permitFragmentIdentifier/fragmentIdentifierPermitted. I also updated the corresponding section in the spec - please see link . If there is need for discussion on this point, please reopen and we can discuss.
        Hide
        Neil Griffin added a comment -

        For JavaBean getter/setting consistency, should the permitFragmentIdentifier and fragmentIdentifierPermitted methods be named isFragmentIdentifierPermitted() and setFragmentIdentifierPermitted(boolean) respectively?

        Show
        Neil Griffin added a comment - For JavaBean getter/setting consistency, should the permitFragmentIdentifier and fragmentIdentifierPermitted methods be named isFragmentIdentifierPermitted() and setFragmentIdentifierPermitted(boolean) respectively?
        Hide
        msnicklous added a comment -

        good idea, thanks for the feedback! implemented. See:

        setFragmentIdentifierPermitted
        isFragmentIdentifierPermitted

        Show
        msnicklous added a comment - good idea, thanks for the feedback! implemented. See: setFragmentIdentifierPermitted isFragmentIdentifierPermitted
        Hide
        msnicklous added a comment -

        The methods

        void setFragmentIdentifier(String)
        String getFragmentIdentifier()
        

        have been implemented on the RenderURL interface.

        The consensus in the EG is that authentication is already handled by portal implementations using different mechanisms, so there is no need for the following methods, and they will not be implemented.

        void setAuthenticated(boolean authenticated)
        boolean getAuthenticated()
        

        Regarding isFragmentIdentifierPermitted and etFragmentIdentifierPermitted: The intention of the "permitted" methods was to be able to suppress a fragment identifier set by the portal. A better way to accomplish that goal would be to drop both of the "permitted" methods and redefine the "get" method to return either the fragment identifier previously set by the portal, or that set by the portlet. The portlet could then use the setter to set the value to "null" if no fragment identifier is desired. So these methods have not been implemented.

        Show
        msnicklous added a comment - The methods void setFragmentIdentifier( String ) String getFragmentIdentifier() have been implemented on the RenderURL interface. The consensus in the EG is that authentication is already handled by portal implementations using different mechanisms, so there is no need for the following methods, and they will not be implemented. void setAuthenticated( boolean authenticated) boolean getAuthenticated() Regarding isFragmentIdentifierPermitted and etFragmentIdentifierPermitted: The intention of the "permitted" methods was to be able to suppress a fragment identifier set by the portal. A better way to accomplish that goal would be to drop both of the "permitted" methods and redefine the "get" method to return either the fragment identifier previously set by the portal, or that set by the portlet. The portlet could then use the setter to set the value to "null" if no fragment identifier is desired. So these methods have not been implemented.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: