Feature Request: Variables for Path Components When Building Result Locations in Scenarios
I find myself doing a lot of scenarios where I'm generating new copies of existing files or transforming files from one schema to another. In that case, I often need to output the files into a directory structure that reflects the input file's structure, e.g., the same parent and grandparent but under a different greatgrandparent. I haven't seen a way to do this statically in setting up the output location in a transformation scenario. I can get the input file's path, it's name, and so on, but not just it's parent's or grandparent's folder name. I'm thinking that what I'd really like is the ability to get any component of the input file's path so that I can then construct the result path, something like: ../../../newdir/${parent:3}/${parent:2}/${parent:1}/$cfn-newbit.xml Where the tokens are addressed from nearest (parent) to farthest, as for the ancestor:: axis. If I had that I could have single transform scenarios I could apply to large sets of files in different structures and get the required result without having to rejigger the transform scenario for each different output location. Cheers, E. ————— Eliot Kimber, Owner Contrext, LLC http://contrext.com
There is already the variable ${pdu} which is the URL of the project directory. If that were complemented with ${rppd} for relative path within project directory, that would do the trick, wouldn't it? On 8/02/2014 8:05 am, Eliot Kimber wrote: ....
I'm thinking that what I'd really like is the ability to get any component of the input file's path so that I can then construct the result path, something like:
../../../newdir/${parent:3}/${parent:2}/${parent:1}/$cfn-newbit.xml
Where the tokens are addressed from nearest (parent) to farthest, as for the ancestor:: axis.
If I had that I could have single transform scenarios I could apply to large sets of files in different structures and get the required result without having to rejigger the transform scenario for each different output location.
-- Peter West "For what does it profit a man if he gains the whole world and loses or forfeits himself?"
The key is that I want to reflect directories that are ancestors of the file being processed. For example, say that files can be in project/a/b/c or project/d/e/f and I want to generate files in project/new/a/b/c or project/new/d/e/f--I don't see a way to do that without having different scenarios or modifying the scenario for each different starting directory. It precludes applying the transform to the common parent of both input directories and having it just work. And of course, if I could really have everything I wanted I'd like to be able to apply a regular expression to the incoming filename and then reference groups in order to construct the result filename.... Cheers, E. -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com On 2/7/14, 5:49 PM, "Peter West" <lists@pbw.id.au> wrote:
There is already the variable ${pdu} which is the URL of the project directory. If that were complemented with ${rppd} for relative path within project directory, that would do the trick, wouldn't it?
On 8/02/2014 8:05 am, Eliot Kimber wrote: ....
I'm thinking that what I'd really like is the ability to get any component of the input file's path so that I can then construct the result path, something like:
../../../newdir/${parent:3}/${parent:2}/${parent:1}/$cfn-newbit.xml
Where the tokens are addressed from nearest (parent) to farthest, as for the ancestor:: axis.
If I had that I could have single transform scenarios I could apply to large sets of files in different structures and get the required result without having to rejigger the transform scenario for each different output location.
-- Peter West "For what does it profit a man if he gains the whole world and loses or forfeits himself?" _______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
On 8/02/2014 9:54 am, Eliot Kimber wrote:
The key is that I want to reflect directories that are ancestors of the file being processed.
For example, say that files can be in project/a/b/c or project/d/e/f and I want to generate files in project/new/a/b/c or project/new/d/e/f--I don't see a way to do that without having different scenarios or modifying the scenario for each different starting directory. It precludes applying the transform to the common parent of both input directories and having it just work.
And of course, if I could really have everything I wanted I'd like to be able to apply a regular expression to the incoming filename and then reference groups in order to construct the result filename....
For the most flexibility, let's make ${rppd} the relative path withinproject of ${cdfn}, the current file directory. project/a/b/c would be ${pdu}/${rppd}/${cfn}.whatever project/new/a/b/c would be ${pdu}/new/${rppd}/${cfn}.whateverelse Similarly for project/d/e/f. -- Peter West "For what does it profit a man if he gains the whole world and loses or forfeits himself?"
But I don't necessarily want the full relative path from the project root. In fact, I would almost never want it. Cheers, E. -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com On 2/7/14, 6:09 PM, "Peter West" <lists@pbw.id.au> wrote:
On 8/02/2014 9:54 am, Eliot Kimber wrote:
The key is that I want to reflect directories that are ancestors of the file being processed.
For example, say that files can be in project/a/b/c or project/d/e/f and I want to generate files in project/new/a/b/c or project/new/d/e/f--I don't see a way to do that without having different scenarios or modifying the scenario for each different starting directory. It precludes applying the transform to the common parent of both input directories and having it just work.
And of course, if I could really have everything I wanted I'd like to be able to apply a regular expression to the incoming filename and then reference groups in order to construct the result filename....
For the most flexibility, let's make ${rppd} the relative path withinproject of ${cdfn}, the current file directory.
project/a/b/c would be ${pdu}/${rppd}/${cfn}.whatever project/new/a/b/c would be ${pdu}/new/${rppd}/${cfn}.whateverelse
Similarly for project/d/e/f.
-- Peter West "For what does it profit a man if he gains the whole world and loses or forfeits himself?"
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
On 8/02/2014 10:14 am, Eliot Kimber wrote:
But I don't necessarily want the full relative path from the project root. In fact, I would almost never want it.
Cheers,
E. Notice that my reply has been deleted. That seems to be a result of having the entire message converted to base64 encoding. What is MacOutlook up to?
Anyway, the ${rppd} or ${rdppd} macro would be generally useful. Form what you've said, it seems that the ${env(VARNAME)} option won't do it for you, because you would have to set the variable for each directory level you are processing. The quick and dirty way to get programmability would be to do the conversion, then provide for a sell-out with a given set of ENVVARs, and a known file name in which the shell could return the path of the transformed file, so that Oxygen would be aware of where things ended up. -- Peter West "For what does it profit a man if he gains the whole world and loses or forfeits himself?"
Hi Eliot, Peter, We have a feature request recorded to support a replace function as an editor function (to be used instead of an editor variable). Another idea will be to say somehow that the result should be evaluated as an XPath expression, for example, thus you should be able to use any XPath function. This can be either a checkbox next to a value or we can use something like: ${xpath(...)} and place as argument the string that will be executed as an XPath expression. This will give access not only to regexp but also to other XPath functions like substring-before, substring-after, etc. Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 2/8/14, 2:14 AM, Eliot Kimber wrote:
But I don't necessarily want the full relative path from the project root. In fact, I would almost never want it.
Cheers,
E.
participants (3)
-
Eliot Kimber -
George Cristian Bina -
Peter West