Redirect API Change

I've written a new redirect action that I think should replace Admin.redirectToOriginal and Page.jumpToPage, which were both designed to handle very specific cases, and yet are complicated and otherwise inflexible. Mine uses one parameter and works with any number and combination of known paths and user inputs.

I came across the problem of the old actions when I was working on the file manager. The file manager requires fairly complex redirections. Consider the case of creating a new file.

Once the user has submitted the create form, they need to be redirected to their new page. This url is composed of:
1. The base file manager URL, example: ${page.filerootpath}/index.html?path=
2. The folder that the new file is located in, example: /test/dir/
3. The file name, example: new.html

So, ultimately we should redirect to ${page.filerootpath}/index.html?path=/test/dir/new.html
The problem is that #2 is not known until we actually visit the create form, and #3 is not known until the user enters a filename into the form.

How would the old actions handle this?

Admin.redirectToOriginal:
This takes two request parameters, origURL, and editPath. Usually we end up using this action because in the simplest case, origURL is set to the desired URL and and it simply redirects there.
This can also handle a more complicated case. When editPath is set, it appends "?path=" + editPath + "&cache=false". This would only be useful if our redirected URL used the path= parameter, so I think few pages actually use it.

Page.jumpToPage:
This takes three request parameters, destinationPath, forcedDestinationPath, and redirectPrefix. destinationPath acts like origURL; redirectPrefix will add any prefix to the url, and forcedDestinationPath will override the path if supplied.

Both of these actions handle a maximum of two different pieces of information, and because the example needs three, we would have to use javascript or something to dynamically combine information into one parameter. Also, our parameters on our create file form would need to match the names in the redirect action so they can be reused, so our create file action would end up accepting "destinationPath" as the file name.

My new action takes one parameter, "path-part". It can specify either a string to add to the redirect path, or the name of a parameter to collect as part of the path. Our original example would be written as:

    <input type="hidden" name="path" value="$basePath"/>
        <input type="text" name="name">

     <input type="hidden" name="path-part" value="${page.filerootpath}/index.html?path=" />   
    <input type="hidden" name="path-part" value="req.path" />   
    <input type="hidden" name="path-part" value="req.name" />   
   
The first input is #2, the path that we find out when we load the page. The second input is #3, the name that the user inputs. These are used in the create file action.
The next three inputs specify how to construct the redirect path. They can either specify a literal string, or else the name of a request parameter to look for.
I think this is simpler and much more flexible. Any suggestions for improvement are welcome, especially for the name and syntax of the "path-part" parameter. This technique could be used for any action that accepts a path or long complicated string. Would it be useful anywhere else?