How to override a variable for a block?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

How to override a variable for a block?

wolandscat
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?
Reply | Threaded
Open this post in threaded view
|

Re: How to override a variable for a block?

mojavelinux
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.


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?


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/How-to-override-a-variable-for-a-block-tp6693.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML


--
Dan Allen | @mojavelinux | https://twitter.com/mojavelinux
Reply | Threaded
Open this post in threaded view
|

Re: How to override a variable for a block?

wolandscat
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