Click
  1. Click
  2. CLK-543

Refactor AbstractLink to Link and include Simple/External Link functionality.

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 3.0.0
    • Component/s: extras
    • Labels:

      Description

      There doesn't seem to be any "simple link" control in Click to be able to point to an arbitrary URL (internal but external too).
      There's now the ExternalLink but it's just too specific - extending it would conflict with it's name (maybe a rename would be better).

      In many cases there's no distinction in the application between an internal an external URL (e.g. because the external might be a subdomain).

      Another problem is that AbstractLink is can't be used directly for these simple cases (being abstract).

      Basically a SimpleLink code would look like ExternalLink, but it would have this additional snippet after L:106:
      <code>
      String ctxPath = getContext().getRequest().getContextPath();
      if(!getTargetPath().contains("://"))

      { buffer.append(ctxPath); }

      </code>
      This would allow to use only one control, and in the application logic, depending on the target, to let the control itself render the required context path if needed.
      ----------------------------------------------------------------------
      Update:

      • Refactor abstract AbstractLink class to a concrete class, simply named "Link"
      • Include basic Link functionality in this Link class - something like SimpleLink and ExternalLink
      • Deprecate ExternalLink

      Users will be able to use the Link control directly so there will be no confusions.
      (Most of the time they use ActionLink without an action, because AbstractLink is abstract)

        Activity

        Hide
        Adrian A. added a comment -

        > I can see value in this change and I agree that it shouldn't affect existing codebases too much.
        > However 2.3.0 might be the wrong target to introduce this change.
        OK. So we can target then with this change Click 3.0.0

        Show
        Adrian A. added a comment - > I can see value in this change and I agree that it shouldn't affect existing codebases too much. > However 2.3.0 might be the wrong target to introduce this change. OK. So we can target then with this change Click 3.0.0
        Hide
        Bob Schellink added a comment -

        I can see value in this change and I agree that it shouldn't affect existing codebases too much. However 2.3.0 might be the wrong target to introduce this change. We have another issue wrt links in CLK-685, which could also end up affecting backwards compatibility.

        Show
        Bob Schellink added a comment - I can see value in this change and I agree that it shouldn't affect existing codebases too much. However 2.3.0 might be the wrong target to introduce this change. We have another issue wrt links in CLK-685 , which could also end up affecting backwards compatibility.
        Hide
        Joseph Schmidt added a comment -

        > Of course, a much better approach would be to refactor e.g. AbstractLink to Link (and make it non-abstract). Since it's abstract,
        > users don't use it directly, so most of them won't be affected. IMHO Click should be as intuitive as possible, and in the case of a link, > there's nothing more intuitive than "Link" .
        +1 for for changing AbstractLink to Link with the above improvement.
        It could than also include the functionality of ExternalLink (and make it deprecated)

        The less Abstract and fragmented Components the better.
        This would be also background compatible, since users don't use AbstractLink directly, and when compiling their code, they would see the warning that ExternalLink is deprecated.
        New users on the other hand would find the component right away since it would be called "Link" .

        Show
        Joseph Schmidt added a comment - > Of course, a much better approach would be to refactor e.g. AbstractLink to Link (and make it non-abstract). Since it's abstract, > users don't use it directly, so most of them won't be affected. IMHO Click should be as intuitive as possible, and in the case of a link, > there's nothing more intuitive than "Link" . +1 for for changing AbstractLink to Link with the above improvement. It could than also include the functionality of ExternalLink (and make it deprecated) The less Abstract and fragmented Components the better. This would be also background compatible, since users don't use AbstractLink directly, and when compiling their code, they would see the warning that ExternalLink is deprecated. New users on the other hand would find the component right away since it would be called "Link" .
        Hide
        Adrian A. added a comment -

        >How about developing some conventions about appending the context path to ExternalLink and updating the
        >Javadoc to make it more generalised.
        Most important of course, would be the functionality, so if it includes the above snippet than it would be an improvement to the actual situation. Because of the "historical naming" however, many users won't "guess" to use it.

        Of course, a much better approach would be to refactor e.g. AbstractLink to Link (and make it non-abstract). Since it's abstract, users don't use it directly, so most of them won't be affected. IMHO Click should be as intuitive as possible, and in the case of a link, there's nothing more intuitive than "Link" .

        Show
        Adrian A. added a comment - >How about developing some conventions about appending the context path to ExternalLink and updating the >Javadoc to make it more generalised. Most important of course, would be the functionality, so if it includes the above snippet than it would be an improvement to the actual situation. Because of the "historical naming" however, many users won't "guess" to use it. Of course, a much better approach would be to refactor e.g. AbstractLink to Link (and make it non-abstract). Since it's abstract, users don't use it directly, so most of them won't be affected. IMHO Click should be as intuitive as possible, and in the case of a link, there's nothing more intuitive than "Link" .
        Hide
        Malcolm Edgar added a comment -

        ExternalLink is supposed to be used for generating arbitary anchor tags. I would agree SimpleLink or Link might be a better name, but that's what we have. The name dates back to a component I added to Tapestry back in 2.x.

        How about developing some conventions about appending the context path to ExternalLink and updating the Javadoc to make it more generalised.

        Show
        Malcolm Edgar added a comment - ExternalLink is supposed to be used for generating arbitary anchor tags. I would agree SimpleLink or Link might be a better name, but that's what we have. The name dates back to a component I added to Tapestry back in 2.x. How about developing some conventions about appending the context path to ExternalLink and updating the Javadoc to make it more generalised.

          People

          • Assignee:
            Adrian A.
            Reporter:
            Adrian A.
          • Votes:
            3 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development