Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
I have a lot of variables defining paths of specifications so each specification can refer to others, and all the concrete URLs can be changed easily in one place if need be.
Here's an example: This specification is in the {spec_status} state. The development version of this document can be found at {openehr_rm_common}[{openehr_rm_common}^]. The variable openehr_rm_common contains a reference to another variable {rm_release}, which can be set to things like 'latest', 'Release-1.0.2' and so on. In the particular para quoted above, I always want the variable rm_release to be 'latest', even when I set rm_release to Release-1.2.5 from the command line. So it's a reversal of what seems to be possible in the current system. It seems an obvious thing to want, and I thought that maybe something like this would work: [rm_release="latest"] This specification is in the {spec_status} state. The development version of this document can be found at {openehr_rm_common}[{openehr_rm_common}^]. But it doesn't. So far I can't find any way to solve this problem other than to define a whole parallel set of variables like openehr_rm_common_latest, of which there will be about 30. Which seems painful. Anyone have any ideas? |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Administrator
|
All attribute references are scoped to the document (i.e., document attributes). You must therefore use an attribute entry (not a block attribute, which is fundamentally a different thing) to change the value of a document attribute. :spec_status: open This specification is in the {spec_status} state.Cheers, -Dan On Fri, Jan 25, 2019 at 3:20 PM wolandscat [via Asciidoctor :: Discussion] <[hidden email]> wrote: I have a lot of variables defining paths of specifications so each specification can refer to others, and all the concrete URLs can be changed easily in one place if need be. ... [show rest of quote] -- Dan Allen | @mojavelinux | https://twitter.com/mojavelinux |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Dan,
thanks for looking. It doesn't work - well, what you said undoubtedly does work, but the problem is that the variable in the para is {rm_common} which is a long path, and defined in terms of other variables, including {rm_release}, which is the variable that can take a value like 'latest', 'Release-1.2.3' etc. So by the time processing arrives at the para in question, it has already done an 'include' on the file containing the def of {rm_common}, and it (I presume) evaluates it right then, using whatever the value is for included vars like {rm_release}. So when it gets to my para, it already has a value for {rm_common}, so it won't re-evaluate with an over-ridden value for {rm_release}. So the following won't do anything interesting at all (and it doesn't): :rm_release: latest xxxxxxxxx xxxxxx xxxxxxxxx {rm_common} xxxxxxx xxxxx The only way to fix this would be if a dynamic re-evaluation of a variable's original definition could be forced, but I don't think that is possible. So I'll need to find another solution. - thomas |
Free forum by Nabble | Edit this page |