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
        julien_viet added a comment -

        I am in favor of this, however I think we should not use the "protected" name as it is a reserved java keyword and that could raise issues with scripting language such as Groovy that supports natively properties (i.e write url.protected = true).

        We have similar concern with GateIn portlet container and we named it "authenticated".

        Show
        julien_viet added a comment - I am in favor of this, however I think we should not use the "protected" name as it is a reserved java keyword and that could raise issues with scripting language such as Groovy that supports natively properties (i.e write url.protected = true). We have similar concern with GateIn portlet container and we named it "authenticated".
        Hide
        msnicklous added a comment -

        I agree on the naming. So then it would become:

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

        void setAuthenticated(Boolean)

        Show
        msnicklous added a comment - I agree on the naming. So then it would become: 2) add a method to create URLs that required the user to log in before they can access the URL void setAuthenticated(Boolean)
        Hide
        Neil Griffin added a comment -

        +1 these are very nice additions.

        The term fragment identifier is used by the HTML spec but I wonder if getNamedAnchor/setNamedAnchor would be more meaningful to portlet developers?

        Show
        Neil Griffin added a comment - +1 these are very nice additions. The term fragment identifier is used by the HTML spec but I wonder if getNamedAnchor/setNamedAnchor would be more meaningful to portlet developers?
        Hide
        andre.hagemeier added a comment -

        Why would the wording "fragment identifier" be a problem? That's basically what the idea is about, isn't it?

        Show
        andre.hagemeier added a comment - Why would the wording "fragment identifier" be a problem? That's basically what the idea is about, isn't it?
        Hide
        Neil Griffin added a comment -

        My impression is that "named anchor" is a term that would be more easily recognized by developers.

        Show
        Neil Griffin added a comment - My impression is that "named anchor" is a term that would be more easily recognized by developers.
        Hide
        msnicklous added a comment -

        Google trend information about terms "Fragment Identifier" and "Named Anchor". Original information found here

        Show
        msnicklous added a comment - Google trend information about terms "Fragment Identifier" and "Named Anchor". Original information found here
        Hide
        msnicklous added a comment -

        Based on info from Google trends, it looks like "Named Anchor" would win out. Neither term is particularly popular compared to "Ben Affleck" for example, but quite a few more people seem to search for "named anchor" than for "fragment identifier".

        (Note that I wasn't able to use the "embed" string provided by Google, because Jira doesn't let me paste script into the post. But you can follow the link above to view the original data.)

        On the other hand, "fragment identifier" is the official technical term that can be found in RFC 3986 and other technical literature, while "named anchor" tends more towards web site design (imho). And the fragment identifier can also be used for more than just addressing a named HTML anchor tag - it could provide additional information on a resource URL, for example.

        So I am kind of partial to using the precise term as the method name, but explaining it to be a named anchor in the description.

        I would also note that adding a fragment identifier to a render URL or a resource URL makes sense, but adding one to an action URL not so much. For now, I would add setFragmentIdentifier to BaseURL, but if we decide to add dedicated interfaces for ActionURL and RenderURL, I would move setFragmentIdentifier to RenderURL and ResourceURL, just for the sake of clarity.

        And naturally setAuthenticated makes sense for all URLs, so it clearly belongs in BaseURL.

        Show
        msnicklous added a comment - Based on info from Google trends , it looks like "Named Anchor" would win out. Neither term is particularly popular compared to "Ben Affleck" for example, but quite a few more people seem to search for "named anchor" than for "fragment identifier". (Note that I wasn't able to use the "embed" string provided by Google, because Jira doesn't let me paste script into the post. But you can follow the link above to view the original data.) On the other hand, "fragment identifier" is the official technical term that can be found in RFC 3986 and other technical literature, while "named anchor" tends more towards web site design (imho). And the fragment identifier can also be used for more than just addressing a named HTML anchor tag - it could provide additional information on a resource URL, for example. So I am kind of partial to using the precise term as the method name, but explaining it to be a named anchor in the description. I would also note that adding a fragment identifier to a render URL or a resource URL makes sense, but adding one to an action URL not so much. For now, I would add setFragmentIdentifier to BaseURL, but if we decide to add dedicated interfaces for ActionURL and RenderURL, I would move setFragmentIdentifier to RenderURL and ResourceURL, just for the sake of clarity. And naturally setAuthenticated makes sense for all URLs, so it clearly belongs in BaseURL.
        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

          People

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

            Dates

            • Created:
              Updated:
              Resolved: