Resetting nested attribute reference values

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

Resetting nested attribute reference values

trost
Hello--

I am having trouble finding information about something you might call "nested references" in Asciidoc--i.e., a user attribute reference that points to a value that contains another user attribute reference.  In particular, I want to be able to reset the value of the lower-level reference and then have that new value be rendered by the upper-level reference without having to also reset the value of the upper-level reference, if that makes sense.

To illustrate the problem, consider the following example:

:fruit:      orange
:phrase: {fruit} is a kind of fruit.
{phrase}

In this simplistic example, Asciidoctor would render "orange is a kind of fruit".

But, if I wanted to reset the value of "fruit"...

:fruit:      orange
:phrase: {fruit} is a kind of fruit.
:fruit:      apple
{phrase}

...Asciidoctor will still render "orange is a kind of fruit".  I want Asciidoctor to reset the value of "fruit" within the "phrase" value, without having to explicitly reset the "phrase" attribute after the "apple" line.  Is that kind of functionality supported?
Reply | Threaded
Open this post in threaded view
|

Re: Resetting nested attribute reference values

mojavelinux
Administrator
@trost,

By default, attribute values are not recomputed. Therefore, reassigning fruit has no affect on phrase because phrase has already been resolved.

I looked into deferring the resolution of the attribute references when defining the attribute. To do that, you would use:

:phrase: pass:c[{fruit} is a kind of fruit]

While that prevents the attribute reference from being resolved at assignment, there's no way in AsciiDoc to have it be resolved later (aside from writing an extension*). The problem is, when you reference {phrase}, it only resolves the value of phrase, not the attribute references it contains.

Unless there's something I'm not thinking of, I don't think there's a way to do what you want to do currently. AsciiDoc attributes weren't designed for that use case. We could consider a way to recursively resolve attribute references after Asciidoctor 2.0.0.

Cheers,

-Dan

You could write an inline macro extension called "resolve-deep" (e.g., resolve-deep:phrase[]) that resolves attribute references inside of an attribute value.

On Thu, Jan 24, 2019 at 4:51 PM trost [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Hello--

I am having trouble finding information about something you might call "nested references" in Asciidoc--i.e., a user attribute reference that points to a value that contains another user attribute reference.  In particular, I want to be able to reset the value of the lower-level reference and then have that new value be rendered by the upper-level reference without having to also reset the value of the upper-level reference, if that makes sense.

To illustrate the problem, consider the following example:

:fruit:      orange
:phrase: {fruit} is a kind of fruit.
{phrase}

In this simplistic example, Asciidoctor would render "orange is a kind of fruit".

But, if I wanted to reset the value of "fruit"...

:fruit:      orange
:phrase: {fruit} is a kind of fruit.
:fruit:      apple
{phrase}

...Asciidoctor will still render "orange is a kind of fruit".  I want Asciidoctor to reset the value of "fruit" within the "phrase" value, without having to explicitly reset the "phrase" attribute after the "apple" line.  Is that kind of functionality supported?


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Resetting-nested-attribute-reference-values-tp6690.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: Resetting nested attribute reference values

trost
Dan,

Thanks for the reply!

For now, I'll look for a workaround solution for my use-case.

It doesn't seem like coding support for something like this would be that difficult, provided you're familiar with Ruby, which I'm not :\  Is this where you envision such a change going?

-Tyson