Implement page variable functionality by jamos-tay · Pull Request #627 · MarkBind/markbind

jamos-tay · 2019-01-23T14:24:37Z

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [X] Enhancement to an existing feature

What is the rationale for this request?

Extension of included variable functionality, allow users to specify local variables within the same page.

What changes did you make? (Give an overview)

Users can specify local variables with the variable key word:

<variablename="color">red</variable>

They can use it within the page like normal variables.

Is there anything you'd like reviewers to focus on?

Should variables cascade into includes? I'm thinking no, it can be confusing if the user is trying to trace where a variable came from and can't find it. If the user wishes for them to be used they can include it specifically:

<variablename="x">5</variable><include...><spanid="x">{{ x }}</span></include>

All page variables are processed before any rendering is done, so users cannot change the value of variables mid page:

<variable name="x">5</variable>
{{ x }} // 6
<variable name="x">6</variable>
{{ x }} // 6

I don't think supporting this is a good idea since we won't be able to use nunjucks and would have to write our own parser. Users can use {% set %} as an alternative. Currently a warning is shown if the user tries to reassign a variable.

damithc · 2019-01-23T14:33:17Z

All page variables are processed before any rendering is done, so users cannot change the value of variables mid page:

should we call them constants instead?

<const name="MAX_SIZE">5</const>

jamos-tay · 2019-01-23T17:10:41Z

We could, but aren't the global variables kind of like constants too, in that case?

damithc · 2019-01-24T01:09:39Z

We could, but aren't the global variables kind of like constants too, in that case?

At the moment, they are too.

yamgent · 2019-01-24T05:02:25Z

should we call them constants instead?
<const name="MAX_SIZE">5</const>

But if the users can do a {% set %} on them, then it is confusing to call them constants? :P

acjh · 2019-01-24T05:09:09Z

We may also consider implementing overriding the sub-sites' variables in future.

damithc · 2019-01-24T05:35:06Z

But if the users can do a {% set %} on them, then it is confusing to call them constants? :P

That's true.

We have several types of variables each behaving in a different way; we should come up with a good terminology to differentiate them.

jamos-tay · 2019-01-25T13:13:36Z

Sure - maybe we should just leave it as variable for now then since that's how variables.md is named?

jamos-tay · 2019-01-28T07:17:06Z

Implemented page variables + included variables, should be ready

jamos-tay · 2019-01-29T11:34:42Z

Updated, page variables can now cascade into included files.

Page variables are now treated exactly like included variables, global > outer > inner priority etc.. The only difference is how they're defined (span vs variable)

Update documentation

jamos-tay · 2019-01-31T13:20:30Z

Updated

damithc · 2019-02-04T11:59:05Z

Good work on this feature @jamos-tay (and @yamgent, @acjh). I've started using it and worked great so far. What do you guys think of allowing the reuse context to access page variables using the # operator?

e.g., <include src="foo.md#title"/> (where title is a page variable in foo.md)

acjh · 2019-02-04T12:05:39Z

Isn't that the syntax for fragments?

damithc · 2019-02-04T12:08:34Z

Isn't that the syntax for fragments?

Yes. a variable is like a hidden fragment, right? Of course name clashes is a concern but in that case we can follow the same rules as multiple segments with same ID?

jamos-tay · 2019-02-04T12:40:58Z

Hmm... I think that implementation might have a few unwanted implications.

For example, if the reasoning is <include src="foo.md#title"/> renders <variable name="title"> fragment in the parent page and therefore title should apply to the parent page, then wouldn't <include src="foo.md"/> render all the variables in foo.md in the parent page and thus all inner variables should be applied? Which seems to be a case of an inner page modifying an outer page's content, which might go against what we want.

damithc · 2019-02-04T13:41:08Z

For example, if the reasoning is <include src="foo.md#title"/> renders <variable name="title"> fragment in the parent page and therefore title should apply to the parent page, then wouldn't <include src="foo.md"/> render all the variables in foo.md in the parent page and thus all inner variables should be applied? Which seems to be a case of an inner page modifying an outer page's content, which might go against what we want.

Accessing a variable value from the parent doesn't mean the variable is raised to the level of the parent. It's simply reading the value only.

I was hoping to use variables as properties of the page. e.g., title, summary, level, difficulty etc. Similar to a public varaible of a Java object, it makes sense to be able to access properties of the object from outside.

Of course, I can use abc instead. Using variables is slightly more convenient.

jamos-tay · 2019-02-08T07:02:36Z

Hmm okay, that seems reasonable

It would have to be treated separately from a regular include, though

damithc · 2019-02-08T10:34:55Z

Moved the discussion to #682

jamos-tay · 2019-01-23T14:24:37Z

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [X] Enhancement to an existing feature

Fixes#575

What is the rationale for this request?

Extension of included variable functionality, allow users to specify local variables within the same page.

What changes did you make? (Give an overview)

Users can specify local variables with the variable key word:

<variablename="color">red</variable>

They can use it within the page like normal variables.

Is there anything you'd like reviewers to focus on?

Should variables cascade into includes? I'm thinking no, it can be confusing if the user is trying to trace where a variable came from and can't find it. If the user wishes for them to be used they can include it specifically:

<variablename="x">5</variable><include...><spanid="x">{{ x }}</span></include>

All page variables are processed before any rendering is done, so users cannot change the value of variables mid page:

<variable name="x">5</variable>
{{ x }} // 6
<variable name="x">6</variable>
{{ x }} // 6

I don't think supporting this is a good idea since we won't be able to use nunjucks and would have to write our own parser. Users can use {% set %} as an alternative. Currently a warning is shown if the user tries to reassign a variable.

damithc · 2019-01-23T14:33:17Z

All page variables are processed before any rendering is done, so users cannot change the value of variables mid page:

should we call them constants instead?

<const name="MAX_SIZE">5</const>

jamos-tay · 2019-01-23T17:10:41Z

We could, but aren't the global variables kind of like constants too, in that case?

damithc · 2019-01-24T01:09:39Z

We could, but aren't the global variables kind of like constants too, in that case?

At the moment, they are too.

yamgent · 2019-01-24T05:02:25Z

should we call them constants instead?
<const name="MAX_SIZE">5</const>

But if the users can do a {% set %} on them, then it is confusing to call them constants? :P

acjh · 2019-01-24T05:09:09Z

We may also consider implementing overriding the sub-sites' variables in future.

damithc · 2019-01-24T05:35:06Z

But if the users can do a {% set %} on them, then it is confusing to call them constants? :P

That's true.

We have several types of variables each behaving in a different way; we should come up with a good terminology to differentiate them.

jamos-tay · 2019-01-25T13:13:36Z

Sure - maybe we should just leave it as variable for now then since that's how variables.md is named?

jamos-tay · 2019-01-28T07:17:06Z

Implemented page variables + included variables, should be ready

jamos-tay · 2019-01-29T11:34:42Z

Updated, page variables can now cascade into included files.

Page variables are now treated exactly like included variables, global > outer > inner priority etc.. The only difference is how they're defined (span vs variable)

Update documentation

jamos-tay · 2019-01-31T13:20:30Z

Updated

damithc · 2019-02-04T11:59:05Z

Good work on this feature @jamos-tay (and @yamgent, @acjh). I've started using it and worked great so far. What do you guys think of allowing the reuse context to access page variables using the # operator?

e.g., <include src="foo.md#title"/> (where title is a page variable in foo.md)

acjh · 2019-02-04T12:05:39Z

Isn't that the syntax for fragments?

damithc · 2019-02-04T12:08:34Z

Isn't that the syntax for fragments?

Yes. a variable is like a hidden fragment, right? Of course name clashes is a concern but in that case we can follow the same rules as multiple segments with same ID?

jamos-tay · 2019-02-04T12:40:58Z

Hmm... I think that implementation might have a few unwanted implications.

For example, if the reasoning is <include src="foo.md#title"/> renders <variable name="title"> fragment in the parent page and therefore title should apply to the parent page, then wouldn't <include src="foo.md"/> render all the variables in foo.md in the parent page and thus all inner variables should be applied? Which seems to be a case of an inner page modifying an outer page's content, which might go against what we want.

damithc · 2019-02-04T13:41:08Z

For example, if the reasoning is <include src="foo.md#title"/> renders <variable name="title"> fragment in the parent page and therefore title should apply to the parent page, then wouldn't <include src="foo.md"/> render all the variables in foo.md in the parent page and thus all inner variables should be applied? Which seems to be a case of an inner page modifying an outer page's content, which might go against what we want.

Accessing a variable value from the parent doesn't mean the variable is raised to the level of the parent. It's simply reading the value only.

I was hoping to use variables as properties of the page. e.g., title, summary, level, difficulty etc. Similar to a public varaible of a Java object, it makes sense to be able to access properties of the object from outside.

Of course, I can use abc instead. Using variables is slightly more convenient.

jamos-tay · 2019-02-08T07:02:36Z

Hmm okay, that seems reasonable

It would have to be treated separately from a regular include, though

damithc · 2019-02-08T10:34:55Z

Moved the discussion to #682

jamos-tay · 2019-01-23T14:24:37Z

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [X] Enhancement to an existing feature

Fixes#575

What is the rationale for this request?

Extension of included variable functionality, allow users to specify local variables within the same page.

What changes did you make? (Give an overview)

Users can specify local variables with the variable key word:

<variablename="color">red</variable>

They can use it within the page like normal variables.

Is there anything you'd like reviewers to focus on?

Should variables cascade into includes? I'm thinking no, it can be confusing if the user is trying to trace where a variable came from and can't find it. If the user wishes for them to be used they can include it specifically:

<variablename="x">5</variable><include...><spanid="x">{{ x }}</span></include>

All page variables are processed before any rendering is done, so users cannot change the value of variables mid page:

<variable name="x">5</variable>
{{ x }} // 6
<variable name="x">6</variable>
{{ x }} // 6

I don't think supporting this is a good idea since we won't be able to use nunjucks and would have to write our own parser. Users can use {% set %} as an alternative. Currently a warning is shown if the user tries to reassign a variable.

damithc · 2019-01-23T14:33:17Z

All page variables are processed before any rendering is done, so users cannot change the value of variables mid page:

should we call them constants instead?

<const name="MAX_SIZE">5</const>

jamos-tay · 2019-01-23T17:10:41Z

We could, but aren't the global variables kind of like constants too, in that case?

damithc · 2019-01-24T01:09:39Z

We could, but aren't the global variables kind of like constants too, in that case?

At the moment, they are too.

yamgent · 2019-01-24T05:02:25Z

should we call them constants instead?
<const name="MAX_SIZE">5</const>

But if the users can do a {% set %} on them, then it is confusing to call them constants? :P

acjh · 2019-01-24T05:09:09Z

We may also consider implementing overriding the sub-sites' variables in future.

damithc · 2019-01-24T05:35:06Z

But if the users can do a {% set %} on them, then it is confusing to call them constants? :P

That's true.

We have several types of variables each behaving in a different way; we should come up with a good terminology to differentiate them.

jamos-tay · 2019-01-25T13:13:36Z

Sure - maybe we should just leave it as variable for now then since that's how variables.md is named?

jamos-tay · 2019-01-28T07:17:06Z

Implemented page variables + included variables, should be ready

jamos-tay · 2019-01-29T11:34:42Z

Updated, page variables can now cascade into included files.

Page variables are now treated exactly like included variables, global > outer > inner priority etc.. The only difference is how they're defined (span vs variable)

Update documentation

jamos-tay · 2019-01-31T13:20:30Z

Updated

damithc · 2019-02-04T11:59:05Z

Good work on this feature @jamos-tay (and @yamgent, @acjh). I've started using it and worked great so far. What do you guys think of allowing the reuse context to access page variables using the # operator?

e.g., <include src="foo.md#title"/> (where title is a page variable in foo.md)

acjh · 2019-02-04T12:05:39Z

Isn't that the syntax for fragments?

damithc · 2019-02-04T12:08:34Z

Isn't that the syntax for fragments?

Yes. a variable is like a hidden fragment, right? Of course name clashes is a concern but in that case we can follow the same rules as multiple segments with same ID?

jamos-tay · 2019-02-04T12:40:58Z

Hmm... I think that implementation might have a few unwanted implications.

For example, if the reasoning is <include src="foo.md#title"/> renders <variable name="title"> fragment in the parent page and therefore title should apply to the parent page, then wouldn't <include src="foo.md"/> render all the variables in foo.md in the parent page and thus all inner variables should be applied? Which seems to be a case of an inner page modifying an outer page's content, which might go against what we want.

damithc · 2019-02-04T13:41:08Z

For example, if the reasoning is <include src="foo.md#title"/> renders <variable name="title"> fragment in the parent page and therefore title should apply to the parent page, then wouldn't <include src="foo.md"/> render all the variables in foo.md in the parent page and thus all inner variables should be applied? Which seems to be a case of an inner page modifying an outer page's content, which might go against what we want.

Accessing a variable value from the parent doesn't mean the variable is raised to the level of the parent. It's simply reading the value only.

I was hoping to use variables as properties of the page. e.g., title, summary, level, difficulty etc. Similar to a public varaible of a Java object, it makes sense to be able to access properties of the object from outside.

Of course, I can use abc instead. Using variables is slightly more convenient.

jamos-tay · 2019-02-08T07:02:36Z

Hmm okay, that seems reasonable

It would have to be treated separately from a regular include, though

damithc · 2019-02-08T10:34:55Z

Moved the discussion to #682

jamos-tay · 2019-01-23T14:24:37Z

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [X] Enhancement to an existing feature

Fixes#575

What is the rationale for this request?

Extension of included variable functionality, allow users to specify local variables within the same page.

What changes did you make? (Give an overview)

Users can specify local variables with the variable key word:

<variablename="color">red</variable>

They can use it within the page like normal variables.

Is there anything you'd like reviewers to focus on?

Should variables cascade into includes? I'm thinking no, it can be confusing if the user is trying to trace where a variable came from and can't find it. If the user wishes for them to be used they can include it specifically:

<variablename="x">5</variable><include...><spanid="x">{{ x }}</span></include>

All page variables are processed before any rendering is done, so users cannot change the value of variables mid page:

<variable name="x">5</variable>
{{ x }} // 6
<variable name="x">6</variable>
{{ x }} // 6

I don't think supporting this is a good idea since we won't be able to use nunjucks and would have to write our own parser. Users can use {% set %} as an alternative. Currently a warning is shown if the user tries to reassign a variable.

damithc · 2019-01-23T14:33:17Z

All page variables are processed before any rendering is done, so users cannot change the value of variables mid page:

should we call them constants instead?

<const name="MAX_SIZE">5</const>

jamos-tay · 2019-01-23T17:10:41Z

We could, but aren't the global variables kind of like constants too, in that case?

damithc · 2019-01-24T01:09:39Z

We could, but aren't the global variables kind of like constants too, in that case?

At the moment, they are too.

yamgent · 2019-01-24T05:02:25Z

should we call them constants instead?
<const name="MAX_SIZE">5</const>

But if the users can do a {% set %} on them, then it is confusing to call them constants? :P

acjh · 2019-01-24T05:09:09Z

We may also consider implementing overriding the sub-sites' variables in future.

damithc · 2019-01-24T05:35:06Z

But if the users can do a {% set %} on them, then it is confusing to call them constants? :P

That's true.

We have several types of variables each behaving in a different way; we should come up with a good terminology to differentiate them.

jamos-tay · 2019-01-25T13:13:36Z

Sure - maybe we should just leave it as variable for now then since that's how variables.md is named?

jamos-tay · 2019-01-28T07:17:06Z

Implemented page variables + included variables, should be ready

jamos-tay · 2019-01-29T11:34:42Z

Updated, page variables can now cascade into included files.

Page variables are now treated exactly like included variables, global > outer > inner priority etc.. The only difference is how they're defined (span vs variable)

Update documentation

jamos-tay · 2019-01-31T13:20:30Z

Updated

damithc · 2019-02-04T11:59:05Z

Good work on this feature @jamos-tay (and @yamgent, @acjh). I've started using it and worked great so far. What do you guys think of allowing the reuse context to access page variables using the # operator?

e.g., <include src="foo.md#title"/> (where title is a page variable in foo.md)

acjh · 2019-02-04T12:05:39Z

Isn't that the syntax for fragments?

damithc · 2019-02-04T12:08:34Z

Isn't that the syntax for fragments?

Yes. a variable is like a hidden fragment, right? Of course name clashes is a concern but in that case we can follow the same rules as multiple segments with same ID?

jamos-tay · 2019-02-04T12:40:58Z

Hmm... I think that implementation might have a few unwanted implications.

For example, if the reasoning is <include src="foo.md#title"/> renders <variable name="title"> fragment in the parent page and therefore title should apply to the parent page, then wouldn't <include src="foo.md"/> render all the variables in foo.md in the parent page and thus all inner variables should be applied? Which seems to be a case of an inner page modifying an outer page's content, which might go against what we want.

damithc · 2019-02-04T13:41:08Z

For example, if the reasoning is <include src="foo.md#title"/> renders <variable name="title"> fragment in the parent page and therefore title should apply to the parent page, then wouldn't <include src="foo.md"/> render all the variables in foo.md in the parent page and thus all inner variables should be applied? Which seems to be a case of an inner page modifying an outer page's content, which might go against what we want.

Accessing a variable value from the parent doesn't mean the variable is raised to the level of the parent. It's simply reading the value only.

I was hoping to use variables as properties of the page. e.g., title, summary, level, difficulty etc. Similar to a public varaible of a Java object, it makes sense to be able to access properties of the object from outside.

Of course, I can use abc instead. Using variables is slightly more convenient.

jamos-tay · 2019-02-08T07:02:36Z

Hmm okay, that seems reasonable

It would have to be treated separately from a regular include, though

damithc · 2019-02-08T10:34:55Z

Moved the discussion to #682

jamos-tay · 2019-01-23T14:24:37Z

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [X] Enhancement to an existing feature

Fixes#575

What is the rationale for this request?

Extension of included variable functionality, allow users to specify local variables within the same page.

What changes did you make? (Give an overview)

Users can specify local variables with the variable key word:

<variablename="color">red</variable>

They can use it within the page like normal variables.

Is there anything you'd like reviewers to focus on?

Should variables cascade into includes? I'm thinking no, it can be confusing if the user is trying to trace where a variable came from and can't find it. If the user wishes for them to be used they can include it specifically:

<variablename="x">5</variable><include...><spanid="x">{{ x }}</span></include>

All page variables are processed before any rendering is done, so users cannot change the value of variables mid page:

<variable name="x">5</variable>
{{ x }} // 6
<variable name="x">6</variable>
{{ x }} // 6

I don't think supporting this is a good idea since we won't be able to use nunjucks and would have to write our own parser. Users can use {% set %} as an alternative. Currently a warning is shown if the user tries to reassign a variable.

damithc · 2019-01-23T14:33:17Z

All page variables are processed before any rendering is done, so users cannot change the value of variables mid page:

should we call them constants instead?

<const name="MAX_SIZE">5</const>

jamos-tay · 2019-01-23T17:10:41Z

We could, but aren't the global variables kind of like constants too, in that case?

damithc · 2019-01-24T01:09:39Z

We could, but aren't the global variables kind of like constants too, in that case?

At the moment, they are too.

yamgent · 2019-01-24T05:02:25Z

should we call them constants instead?
<const name="MAX_SIZE">5</const>

But if the users can do a {% set %} on them, then it is confusing to call them constants? :P

acjh · 2019-01-24T05:09:09Z

We may also consider implementing overriding the sub-sites' variables in future.

damithc · 2019-01-24T05:35:06Z

But if the users can do a {% set %} on them, then it is confusing to call them constants? :P

That's true.

We have several types of variables each behaving in a different way; we should come up with a good terminology to differentiate them.

jamos-tay · 2019-01-25T13:13:36Z

Sure - maybe we should just leave it as variable for now then since that's how variables.md is named?

jamos-tay · 2019-01-28T07:17:06Z

Implemented page variables + included variables, should be ready

jamos-tay · 2019-01-29T11:34:42Z

Updated, page variables can now cascade into included files.

Page variables are now treated exactly like included variables, global > outer > inner priority etc.. The only difference is how they're defined (span vs variable)

Update documentation

jamos-tay · 2019-01-31T13:20:30Z

Updated

damithc · 2019-02-04T11:59:05Z

Good work on this feature @jamos-tay (and @yamgent, @acjh). I've started using it and worked great so far. What do you guys think of allowing the reuse context to access page variables using the # operator?

e.g., <include src="foo.md#title"/> (where title is a page variable in foo.md)

acjh · 2019-02-04T12:05:39Z

Isn't that the syntax for fragments?

damithc · 2019-02-04T12:08:34Z

Isn't that the syntax for fragments?

Yes. a variable is like a hidden fragment, right? Of course name clashes is a concern but in that case we can follow the same rules as multiple segments with same ID?

jamos-tay · 2019-02-04T12:40:58Z

Hmm... I think that implementation might have a few unwanted implications.

For example, if the reasoning is <include src="foo.md#title"/> renders <variable name="title"> fragment in the parent page and therefore title should apply to the parent page, then wouldn't <include src="foo.md"/> render all the variables in foo.md in the parent page and thus all inner variables should be applied? Which seems to be a case of an inner page modifying an outer page's content, which might go against what we want.

damithc · 2019-02-04T13:41:08Z

For example, if the reasoning is <include src="foo.md#title"/> renders <variable name="title"> fragment in the parent page and therefore title should apply to the parent page, then wouldn't <include src="foo.md"/> render all the variables in foo.md in the parent page and thus all inner variables should be applied? Which seems to be a case of an inner page modifying an outer page's content, which might go against what we want.

Accessing a variable value from the parent doesn't mean the variable is raised to the level of the parent. It's simply reading the value only.

I was hoping to use variables as properties of the page. e.g., title, summary, level, difficulty etc. Similar to a public varaible of a Java object, it makes sense to be able to access properties of the object from outside.

Of course, I can use abc instead. Using variables is slightly more convenient.

jamos-tay · 2019-02-08T07:02:36Z

Hmm okay, that seems reasonable

It would have to be treated separately from a regular include, though

damithc · 2019-02-08T10:34:55Z

Moved the discussion to #682

jamos-tay · 2019-01-23T14:24:37Z

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [X] Enhancement to an existing feature

Fixes#575

What is the rationale for this request?

Extension of included variable functionality, allow users to specify local variables within the same page.

What changes did you make? (Give an overview)

Users can specify local variables with the variable key word:

<variablename="color">red</variable>

They can use it within the page like normal variables.

Is there anything you'd like reviewers to focus on?

Should variables cascade into includes? I'm thinking no, it can be confusing if the user is trying to trace where a variable came from and can't find it. If the user wishes for them to be used they can include it specifically:

<variablename="x">5</variable><include...><spanid="x">{{ x }}</span></include>

All page variables are processed before any rendering is done, so users cannot change the value of variables mid page:

<variable name="x">5</variable>
{{ x }} // 6
<variable name="x">6</variable>
{{ x }} // 6

I don't think supporting this is a good idea since we won't be able to use nunjucks and would have to write our own parser. Users can use {% set %} as an alternative. Currently a warning is shown if the user tries to reassign a variable.

damithc · 2019-01-23T14:33:17Z

All page variables are processed before any rendering is done, so users cannot change the value of variables mid page:

should we call them constants instead?

<const name="MAX_SIZE">5</const>

jamos-tay · 2019-01-23T17:10:41Z

We could, but aren't the global variables kind of like constants too, in that case?

damithc · 2019-01-24T01:09:39Z

We could, but aren't the global variables kind of like constants too, in that case?

At the moment, they are too.

yamgent · 2019-01-24T05:02:25Z

should we call them constants instead?
<const name="MAX_SIZE">5</const>

But if the users can do a {% set %} on them, then it is confusing to call them constants? :P

acjh · 2019-01-24T05:09:09Z

We may also consider implementing overriding the sub-sites' variables in future.

damithc · 2019-01-24T05:35:06Z

But if the users can do a {% set %} on them, then it is confusing to call them constants? :P

That's true.

We have several types of variables each behaving in a different way; we should come up with a good terminology to differentiate them.

jamos-tay · 2019-01-25T13:13:36Z

Sure - maybe we should just leave it as variable for now then since that's how variables.md is named?

jamos-tay · 2019-01-28T07:17:06Z

Implemented page variables + included variables, should be ready

jamos-tay · 2019-01-29T11:34:42Z

Updated, page variables can now cascade into included files.

Page variables are now treated exactly like included variables, global > outer > inner priority etc.. The only difference is how they're defined (span vs variable)

Update documentation

jamos-tay · 2019-01-31T13:20:30Z

Updated

damithc · 2019-02-04T11:59:05Z

Good work on this feature @jamos-tay (and @yamgent, @acjh). I've started using it and worked great so far. What do you guys think of allowing the reuse context to access page variables using the # operator?

e.g., <include src="foo.md#title"/> (where title is a page variable in foo.md)

acjh · 2019-02-04T12:05:39Z

Isn't that the syntax for fragments?

damithc · 2019-02-04T12:08:34Z

Isn't that the syntax for fragments?

Yes. a variable is like a hidden fragment, right? Of course name clashes is a concern but in that case we can follow the same rules as multiple segments with same ID?

jamos-tay · 2019-02-04T12:40:58Z

Hmm... I think that implementation might have a few unwanted implications.

For example, if the reasoning is <include src="foo.md#title"/> renders <variable name="title"> fragment in the parent page and therefore title should apply to the parent page, then wouldn't <include src="foo.md"/> render all the variables in foo.md in the parent page and thus all inner variables should be applied? Which seems to be a case of an inner page modifying an outer page's content, which might go against what we want.

damithc · 2019-02-04T13:41:08Z

For example, if the reasoning is <include src="foo.md#title"/> renders <variable name="title"> fragment in the parent page and therefore title should apply to the parent page, then wouldn't <include src="foo.md"/> render all the variables in foo.md in the parent page and thus all inner variables should be applied? Which seems to be a case of an inner page modifying an outer page's content, which might go against what we want.

Accessing a variable value from the parent doesn't mean the variable is raised to the level of the parent. It's simply reading the value only.

I was hoping to use variables as properties of the page. e.g., title, summary, level, difficulty etc. Similar to a public varaible of a Java object, it makes sense to be able to access properties of the object from outside.

Of course, I can use abc instead. Using variables is slightly more convenient.

jamos-tay · 2019-02-08T07:02:36Z

Hmm okay, that seems reasonable

It would have to be treated separately from a regular include, though

damithc · 2019-02-08T10:34:55Z

Moved the discussion to #682

jamos-tay · 2019-01-23T14:24:37Z

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [X] Enhancement to an existing feature

Fixes#575

What is the rationale for this request?

Extension of included variable functionality, allow users to specify local variables within the same page.

What changes did you make? (Give an overview)

Users can specify local variables with the variable key word:

<variablename="color">red</variable>

They can use it within the page like normal variables.

Is there anything you'd like reviewers to focus on?

Should variables cascade into includes? I'm thinking no, it can be confusing if the user is trying to trace where a variable came from and can't find it. If the user wishes for them to be used they can include it specifically:

<variablename="x">5</variable><include...><spanid="x">{{ x }}</span></include>

All page variables are processed before any rendering is done, so users cannot change the value of variables mid page:

<variable name="x">5</variable>
{{ x }} // 6
<variable name="x">6</variable>
{{ x }} // 6

I don't think supporting this is a good idea since we won't be able to use nunjucks and would have to write our own parser. Users can use {% set %} as an alternative. Currently a warning is shown if the user tries to reassign a variable.

damithc · 2019-01-23T14:33:17Z

All page variables are processed before any rendering is done, so users cannot change the value of variables mid page:

should we call them constants instead?

<const name="MAX_SIZE">5</const>

jamos-tay · 2019-01-23T17:10:41Z

We could, but aren't the global variables kind of like constants too, in that case?

damithc · 2019-01-24T01:09:39Z

We could, but aren't the global variables kind of like constants too, in that case?

At the moment, they are too.

yamgent · 2019-01-24T05:02:25Z

should we call them constants instead?
<const name="MAX_SIZE">5</const>

But if the users can do a {% set %} on them, then it is confusing to call them constants? :P

acjh · 2019-01-24T05:09:09Z

We may also consider implementing overriding the sub-sites' variables in future.

damithc · 2019-01-24T05:35:06Z

But if the users can do a {% set %} on them, then it is confusing to call them constants? :P

That's true.

We have several types of variables each behaving in a different way; we should come up with a good terminology to differentiate them.

jamos-tay · 2019-01-25T13:13:36Z

Sure - maybe we should just leave it as variable for now then since that's how variables.md is named?

jamos-tay · 2019-01-28T07:17:06Z

Implemented page variables + included variables, should be ready

jamos-tay · 2019-01-29T11:34:42Z

Updated, page variables can now cascade into included files.

Page variables are now treated exactly like included variables, global > outer > inner priority etc.. The only difference is how they're defined (span vs variable)

Update documentation

jamos-tay · 2019-01-31T13:20:30Z

Updated

damithc · 2019-02-04T11:59:05Z

Good work on this feature @jamos-tay (and @yamgent, @acjh). I've started using it and worked great so far. What do you guys think of allowing the reuse context to access page variables using the # operator?

e.g., <include src="foo.md#title"/> (where title is a page variable in foo.md)

acjh · 2019-02-04T12:05:39Z

Isn't that the syntax for fragments?

damithc · 2019-02-04T12:08:34Z

Isn't that the syntax for fragments?

Yes. a variable is like a hidden fragment, right? Of course name clashes is a concern but in that case we can follow the same rules as multiple segments with same ID?

jamos-tay · 2019-02-04T12:40:58Z

Hmm... I think that implementation might have a few unwanted implications.

For example, if the reasoning is <include src="foo.md#title"/> renders <variable name="title"> fragment in the parent page and therefore title should apply to the parent page, then wouldn't <include src="foo.md"/> render all the variables in foo.md in the parent page and thus all inner variables should be applied? Which seems to be a case of an inner page modifying an outer page's content, which might go against what we want.

damithc · 2019-02-04T13:41:08Z

For example, if the reasoning is <include src="foo.md#title"/> renders <variable name="title"> fragment in the parent page and therefore title should apply to the parent page, then wouldn't <include src="foo.md"/> render all the variables in foo.md in the parent page and thus all inner variables should be applied? Which seems to be a case of an inner page modifying an outer page's content, which might go against what we want.

Accessing a variable value from the parent doesn't mean the variable is raised to the level of the parent. It's simply reading the value only.

I was hoping to use variables as properties of the page. e.g., title, summary, level, difficulty etc. Similar to a public varaible of a Java object, it makes sense to be able to access properties of the object from outside.

Of course, I can use abc instead. Using variables is slightly more convenient.

jamos-tay · 2019-02-08T07:02:36Z

Hmm okay, that seems reasonable

It would have to be treated separately from a regular include, though

damithc · 2019-02-08T10:34:55Z

Moved the discussion to #682

jamos-tay · 2019-01-23T14:24:37Z

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [X] Enhancement to an existing feature

Fixes#575

What is the rationale for this request?

Extension of included variable functionality, allow users to specify local variables within the same page.

What changes did you make? (Give an overview)

Users can specify local variables with the variable key word:

<variablename="color">red</variable>

They can use it within the page like normal variables.

Is there anything you'd like reviewers to focus on?

Should variables cascade into includes? I'm thinking no, it can be confusing if the user is trying to trace where a variable came from and can't find it. If the user wishes for them to be used they can include it specifically:

<variablename="x">5</variable><include...><spanid="x">{{ x }}</span></include>

All page variables are processed before any rendering is done, so users cannot change the value of variables mid page:

<variable name="x">5</variable>
{{ x }} // 6
<variable name="x">6</variable>
{{ x }} // 6

I don't think supporting this is a good idea since we won't be able to use nunjucks and would have to write our own parser. Users can use {% set %} as an alternative. Currently a warning is shown if the user tries to reassign a variable.

damithc · 2019-01-23T14:33:17Z

All page variables are processed before any rendering is done, so users cannot change the value of variables mid page:

should we call them constants instead?

<const name="MAX_SIZE">5</const>

jamos-tay · 2019-01-23T17:10:41Z

We could, but aren't the global variables kind of like constants too, in that case?

damithc · 2019-01-24T01:09:39Z

We could, but aren't the global variables kind of like constants too, in that case?

At the moment, they are too.

yamgent · 2019-01-24T05:02:25Z

should we call them constants instead?
<const name="MAX_SIZE">5</const>

But if the users can do a {% set %} on them, then it is confusing to call them constants? :P

acjh · 2019-01-24T05:09:09Z

We may also consider implementing overriding the sub-sites' variables in future.

damithc · 2019-01-24T05:35:06Z

But if the users can do a {% set %} on them, then it is confusing to call them constants? :P

That's true.

We have several types of variables each behaving in a different way; we should come up with a good terminology to differentiate them.

jamos-tay · 2019-01-25T13:13:36Z

Sure - maybe we should just leave it as variable for now then since that's how variables.md is named?

jamos-tay · 2019-01-28T07:17:06Z

Implemented page variables + included variables, should be ready

jamos-tay · 2019-01-29T11:34:42Z

Updated, page variables can now cascade into included files.

Page variables are now treated exactly like included variables, global > outer > inner priority etc.. The only difference is how they're defined (span vs variable)

Update documentation

jamos-tay · 2019-01-31T13:20:30Z

Updated

damithc · 2019-02-04T11:59:05Z

Good work on this feature @jamos-tay (and @yamgent, @acjh). I've started using it and worked great so far. What do you guys think of allowing the reuse context to access page variables using the # operator?

e.g., <include src="foo.md#title"/> (where title is a page variable in foo.md)

acjh · 2019-02-04T12:05:39Z

Isn't that the syntax for fragments?

damithc · 2019-02-04T12:08:34Z

Isn't that the syntax for fragments?

Yes. a variable is like a hidden fragment, right? Of course name clashes is a concern but in that case we can follow the same rules as multiple segments with same ID?

jamos-tay · 2019-02-04T12:40:58Z

Hmm... I think that implementation might have a few unwanted implications.

For example, if the reasoning is <include src="foo.md#title"/> renders <variable name="title"> fragment in the parent page and therefore title should apply to the parent page, then wouldn't <include src="foo.md"/> render all the variables in foo.md in the parent page and thus all inner variables should be applied? Which seems to be a case of an inner page modifying an outer page's content, which might go against what we want.

damithc · 2019-02-04T13:41:08Z

For example, if the reasoning is <include src="foo.md#title"/> renders <variable name="title"> fragment in the parent page and therefore title should apply to the parent page, then wouldn't <include src="foo.md"/> render all the variables in foo.md in the parent page and thus all inner variables should be applied? Which seems to be a case of an inner page modifying an outer page's content, which might go against what we want.

Accessing a variable value from the parent doesn't mean the variable is raised to the level of the parent. It's simply reading the value only.

I was hoping to use variables as properties of the page. e.g., title, summary, level, difficulty etc. Similar to a public varaible of a Java object, it makes sense to be able to access properties of the object from outside.

Of course, I can use abc instead. Using variables is slightly more convenient.

jamos-tay · 2019-02-08T07:02:36Z

Hmm okay, that seems reasonable

It would have to be treated separately from a regular include, though

damithc · 2019-02-08T10:34:55Z

Moved the discussion to #682

jamos-tay force-pushed the page-local-variables branch from ff22bd5 to c724d83Compare January 28, 2019 06:31

jamos-tay changed the title ~~[WIP] Implement page variable functionality~~Implement page variable functionalityJan 28, 2019

yamgent requested changes Jan 28, 2019
View reviewed changes

Comment threadtest/test_site/_markbind/variables.md Outdated
Comment threaddocs/userGuide/reusingContents.md Outdated
Comment threaddocs/userGuide/reusingContents.md Outdated

yamgent reviewed Jan 28, 2019
View reviewed changes

Comment threadtest/test_site/testPageVariables.md Outdated

jamos-tay mentioned this pull request Jan 29, 2019
Variables in includes: provide a simpler syntax #642
Closed

yamgent requested changes Jan 31, 2019
View reviewed changes

Comment threadtest/test_site/testPageVariablesInInclude.md Outdated
Comment threaddocs/userGuide/reusingContents.md Outdated

jamos-tay added 8 commits January 31, 2019 21:13

Implement page variable functionality
169ca8b

Add test case and show warning
6decd60

Print file basename only
710bde0

Integrate page and included variables
cdc5743

Update docs for page variables
44a67e9

Rename extractVariables to extractIncludeVariables
c4a393d

Allow page variables to cascade into inner files
69a2761

Rebase on master
eafb330

jamos-tay force-pushed the page-local-variables branch from 0c63d84 to eafb330Compare January 31, 2019 13:15

Fix broken test case
40fee99
Update documentation

yamgent approved these changes Feb 2, 2019
View reviewed changes

yamgent added this to the v1.17.2 milestone Feb 2, 2019

yamgent merged commit 6e2ea26 into MarkBind:masterFeb 4, 2019

jamos-tay mentioned this pull request Feb 8, 2019
Page variables should only be overridden by request #674
Closed

damithc mentioned this pull request Feb 8, 2019
Allow accessing page variables from outside #682
Closed

ang-zeyu mentioned this pull request Sep 13, 2020
Add imported variables #751
Merged