Struts 2
  1. Struts 2
  2. WW-1383

Support action names with slashes

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0.0
    • Component/s: XML Configuration
    • Labels:
      None

      Description

      To better support ReST-style wildcard schemes ("/article/123/view"), the default action mapper should support action names that contain slashes. To do this, instead of assuming everything before the last slash is the namespace, the configured namespaces should be iterated over and explicitly matched.

        Activity

        Hide
        Don Brown added a comment -

        Fixed in svn. The fix involved modifying the ActionMapper interface to support the passing in of Configuration instances.

        Show
        Don Brown added a comment - Fixed in svn. The fix involved modifying the ActionMapper interface to support the passing in of Configuration instances.
        Hide
        Don Brown added a comment -

        This fix broke the expected behavior of actions in the default namespace being allowed to be called from any path prefix. For example, in our showcase, we have an action name of "AjaxRemoteForm" in the default namespace (""), and it needs to be called, among other places, from "/ajax/remoteforms/AjaxRemoteForm". This capability of calling actions from any path prefix in the default namespace stretches back to WebWork 1 and is a somewhat frequently-used feature.

        Therefore, I added a new struts.properties setting, struts.enable.SlashesInActionNames, which, well, enables slashes in action names, but by doing so, you lose the ability to call actions in the default namespace from any path prefix. Therefore, the default value will be "false". If you want to enable slashes in the action names, it is probably because you use wildcards frequently, in which case, you can simulate this feature by putting "*/" in the start of your action name. Therefore, to fix the above, the action name would be "*/AjaxRemoteForm", so now, that action could be called from anywhere.

        I think we should make the default setting to "false" to make WebWork 2 migrations easier, but perhaps for Struts 2.1 we'll default to "true".

        Show
        Don Brown added a comment - This fix broke the expected behavior of actions in the default namespace being allowed to be called from any path prefix. For example, in our showcase, we have an action name of "AjaxRemoteForm" in the default namespace (""), and it needs to be called, among other places, from "/ajax/remoteforms/AjaxRemoteForm". This capability of calling actions from any path prefix in the default namespace stretches back to WebWork 1 and is a somewhat frequently-used feature. Therefore, I added a new struts.properties setting, struts.enable.SlashesInActionNames, which, well, enables slashes in action names, but by doing so, you lose the ability to call actions in the default namespace from any path prefix. Therefore, the default value will be "false". If you want to enable slashes in the action names, it is probably because you use wildcards frequently, in which case, you can simulate this feature by putting "* /" in the start of your action name. Therefore, to fix the above, the action name would be " */AjaxRemoteForm", so now, that action could be called from anywhere. I think we should make the default setting to "false" to make WebWork 2 migrations easier, but perhaps for Struts 2.1 we'll default to "true".
        Hide
        tm_jee added a comment -

        Hi Don,

        What do you think about having a different action mapper that allows slashes as action name, and allow switching by switching action mapper? This way we could avoid having the struts.properties.

        rgds

        Show
        tm_jee added a comment - Hi Don, What do you think about having a different action mapper that allows slashes as action name, and allow switching by switching action mapper? This way we could avoid having the struts.properties. rgds
        Hide
        Don Brown added a comment -

        Well, you'd still need to modify struts.properties to switch over to the new action mapper. Besides, I'm not sure how I feel about a ton of different ActionMappers, each with small features that separate them. We did that with ActionForms in Struts and that didn't turn out too well.

        Show
        Don Brown added a comment - Well, you'd still need to modify struts.properties to switch over to the new action mapper. Besides, I'm not sure how I feel about a ton of different ActionMappers, each with small features that separate them. We did that with ActionForms in Struts and that didn't turn out too well.
        Hide
        tm_jee added a comment -

        I see. I guess if it didn't work out in Struts1, we probably shouldn't try it with Struts2 then.

        Show
        tm_jee added a comment - I see. I guess if it didn't work out in Struts1, we probably shouldn't try it with Struts2 then.
        Hide
        tm_jee added a comment -

        Got another random thought Don,

        What do you think about the concept of a Composite action mapper, that would somehow allows multiple action mapper, and somehow selecting one

        Form first thought, it would complicate the action mapper configuration, not sure if this is a good sign.

        Show
        tm_jee added a comment - Got another random thought Don, What do you think about the concept of a Composite action mapper, that would somehow allows multiple action mapper, and somehow selecting one Form first thought, it would complicate the action mapper configuration, not sure if this is a good sign.
        Hide
        Don Brown added a comment -

        Yeah, I think that deserves more thought. If you come up with something, put out a proposal on dev@ Even if we don't change anything, it is worthwhile, IMO, to raise the issue and start the discussion.

        Show
        Don Brown added a comment - Yeah, I think that deserves more thought. If you come up with something, put out a proposal on dev@ Even if we don't change anything, it is worthwhile, IMO, to raise the issue and start the discussion.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development