Sling
  1. Sling
  2. SLING-2790

Need a way to get the resource of the original request in a subcomponent

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: API
    • Labels:
      None

      Description

      • I have created a component at /apps/training/components/tasklist/tasklist.jsp.
      • I have a page node at /content/training with a sling:resourceType of training/components/page
      • That page has a subnode /content/training/content/tasklist with a sling:resourceType of training/components/tasklist (the tasklist.jsp from above)

      In the tasklist.jsp, I would like to get the path to the resource of the original HTTP request, i.e. /content/training. I expected to get it using slingRequest.getRequestPathInfo().getResourcePath() but that gets me the path to the current resource (/content/training/content/tasklist), not the path to the request.

      Having the original resource in a predefined variable or a call like slingRequest.getOriginalRequestPathInfo() would be very helpful.

        Activity

        Hide
        Carsten Ziegeler added a comment -

        That doesn't convince me It seems that this is a common use case and hiding the information in request attributes is not really user friendly - especially as request attributes do not provide any type safety

        Show
        Carsten Ziegeler added a comment - That doesn't convince me It seems that this is a common use case and hiding the information in request attributes is not really user friendly - especially as request attributes do not provide any type safety
        Hide
        Felix Meschberger added a comment -

        I have a problem with bloating the SlingHttpServletRequest interface even more ....

        Show
        Felix Meschberger added a comment - I have a problem with bloating the SlingHttpServletRequest interface even more ....
        Hide
        Carsten Ziegeler added a comment -

        I'm not against setting request attributes, but what about making this a little bit more user friendly and add as methods to the request object?

        Show
        Carsten Ziegeler added a comment - I'm not against setting request attributes, but what about making this a little bit more user friendly and add as methods to the request object?
        Hide
        Felix Meschberger added a comment -

        > Looking at the javadoc of RequestPathInfo I'm not sure if this is a bug or correct behaviour right now.

        I am not sure we can change the behaviour. If it is like it is, it has always been like this. So we have to fix the JavaDoc.

        I think the intent of the getResource and getRequestPathInfo methods is to always reflect the way how the currently executing servlet/script has been invoked: getResource is the current resource to be processed and getRequestPathInfo reflects the selectors, extension and suffix leading to the selection of the executing servlet.

        I could imagine, that the Sling Main Servlet could in fact set request attributes

        > org.apache.sling.api.request.servlet
        > org.apache.sling.api.request.resource
        > org.apache.sling.api.request.request_path_info

        with the respective request level values (similar to o.a.s.api.include.* which contain the values from the including script/servlet; see SlingConstants in the Sling API).

        Show
        Felix Meschberger added a comment - > Looking at the javadoc of RequestPathInfo I'm not sure if this is a bug or correct behaviour right now. I am not sure we can change the behaviour. If it is like it is, it has always been like this. So we have to fix the JavaDoc. I think the intent of the getResource and getRequestPathInfo methods is to always reflect the way how the currently executing servlet/script has been invoked: getResource is the current resource to be processed and getRequestPathInfo reflects the selectors, extension and suffix leading to the selection of the executing servlet. I could imagine, that the Sling Main Servlet could in fact set request attributes > org.apache.sling.api.request.servlet > org.apache.sling.api.request.resource > org.apache.sling.api.request.request_path_info with the respective request level values (similar to o.a.s.api.include.* which contain the values from the including script/servlet; see SlingConstants in the Sling API).
        Hide
        Carsten Ziegeler added a comment -

        Looking at the javadoc of RequestPathInfo I'm not sure if this is a bug or correct behaviour right now. RequestPathInfo talks about decompositing of the URL so following this docs it should always point to the original request and not to the current resource being processed. So either the implementation is wrong or the javadoc needs an update.

        In any case I think it would make sense to have a method on the request which returns the original/first resource which was targetted by the client

        Show
        Carsten Ziegeler added a comment - Looking at the javadoc of RequestPathInfo I'm not sure if this is a bug or correct behaviour right now. RequestPathInfo talks about decompositing of the URL so following this docs it should always point to the original request and not to the current resource being processed. So either the implementation is wrong or the javadoc needs an update. In any case I think it would make sense to have a method on the request which returns the original/first resource which was targetted by the client

          People

          • Assignee:
            Unassigned
            Reporter:
            Axel Hanikel
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:

              Development