Unexpected output in template

[chadwhitacre]

I am upgrading a (closed-source) project to Aspen 1.0rc2. In one simplate I conditionally assign a variable output in the request-time Python section, and then conditionally show a message based on the truthiness of the variable. Under 1.0rc2, there is an output object in the default simplate context, so the value is always truthy. I know we've touched on this area before, but I forget where things stand: am I supposed to know this somehow and just be careful with a name like that?

I think the only place we ever really hit this was with response, because we'd do an HTTP call from inside a simplate and bind the result to response, which would overwrite the in-progress Aspen response. Should we rename this to aspen_output to avoid the conflict? Should we prefix other names, like path and qs?

if foo:
    output = 'bar'
[---]
{% if output %}{{ output }}{% endif %}

[Changaco]

I suggest always giving a default value to your variables. Instead of leaving output undefined when foo isn't True-ish, give it a default value like None, that should solve the problem.

[Changaco]

I think the only ever place we really hit this was with response,

In AspenWeb/pando.py#426 it was with resource, but as you said it was about writing the variable, not reading it, and we fixed the problem with AspenWeb/pando.py#427.

[Changaco]

Should we rename this to aspen_output to avoid the conflict? Should we prefix other names, like path and qs?

I'm okay with that if it's only at the simplate level (i.e. when building the context in Simplate.render_for_type we replace output with aspen_output). I'm less certain about renaming the variables in the state.

[chadwhitacre]

We could also close this as a dupe of AspenWeb/pando.py#30.

[chadwhitacre]

Or perhaps close that as a dupe of this, since I think we want it in this repo instead of that one.

[Changaco]

#27 is my preferred alternative solution to AspenWeb/pando.py#30.

[chadwhitacre]

Ah, that's right. :-)

Closing in favor of #27.