Issue Details (XML | Word | Printable)

Type: Improvement Improvement
Status: Resolved Resolved
Resolution: Fixed
Priority: Minor Minor
Assignee: msnicklous
Reporter: msnicklous
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.

Two extensions for BaseURL

Created: 03/May/13 11:42 AM   Updated: 29/Aug/13 09:33 AM   Resolved: 28/Aug/13 01:39 PM
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

File Attachments: None
Image Attachments:

1. NamedAnchor-FragmentIdentifier.gif
(13 kB)

Participants: andre.hagemeier, julien_viet, msnicklous and Neil Griffin

 Description  « Hide

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:

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)

julien_viet added a comment - 10/May/13 08:15 AM

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".

msnicklous added a comment - 13/May/13 08:19 AM

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)

Neil Griffin added a comment - 14/May/13 03:31 AM

+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?

andre.hagemeier added a comment - 31/Jul/13 06:01 PM

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

Neil Griffin added a comment - 13/Aug/13 07:04 PM

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

msnicklous added a comment - 23/Aug/13 05:13 AM

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

msnicklous added a comment - 23/Aug/13 06:16 AM

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.

msnicklous added a comment - 23/Aug/13 02:44 PM

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.

authenticated - true, if the URL requires authentication. false, if the URL does not require authentication.

boolean getAuthenticated()

Returns the authentication setting for the URL.

true if the URL requires authentication

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.

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

String getFragmentIdentifier()

Gets the fragment identifier set on the URL.

The fragment identifier set on the URL, or null if no fragment identifier has been set.

msnicklous added a comment - 28/Aug/13 01:39 PM

Resolved by adding several methods to BaseURL:


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.

Neil Griffin added a comment - 28/Aug/13 02:20 PM

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

msnicklous added a comment - 29/Aug/13 09:33 AM

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