Item14687: SET macro documentation related to INCLUDE and topic scope is incorrect.

I understand, from VarSET, that I should be able to use %SET and %INCLUDE to set variables in one file and evaluate them in another. However, I can't make this work (and neither can GeorgeClark).

For an example, please see Sandbox.SET_INCLUDE.

-- RichMorin - 02 May 2018

This is working as designed, and GeorgeClark broke the documentation in a fix for 2.1.6. The original docs stated:

-A preference setting created via %SET will only be usable on the topic where it has been found by the parser, similar to normal preference settings. Each call to %INCLUDE opens a new scope for preference variables. An %INCLUDE of another topic containing a %SET statement will _not_define those values in the including topic's scope.

I removed that statement from the 2.1.6 docs. I was under the mistaken impression that the primary use case for %SET macro was to allow setting across includes.

-- GeorgeClark - 02 May 2018

If it's working as designed, the design is incomplete. I use lots of languages for programming, templating, and so forth. In general, they let me include arbitrary content from other files. So, IMNSHO, this is broken.

Can't someone add an %INCLUDE option or an alternate command that will bring in these settings? This has been annoying VickiBrown and me (at least) for decades! I'm trying to clean up my TML by hiding the URL definitions (etc) somewhere else (eg, a project-specific file). I know there's a workaround, but adding syntax such as the following won't make things tidier:

[[%CALC{$GET(WP_Ruby)}%][Ruby]]

-- RichMorin - 02 May 2018

%SET is not broken, not even by design. The documentation is, agreed.

The macro is a simple frontend to the perl API underneath Foswiki::Func::setSessionPreferences().

%INCLUDE creates a temporary session scope where the variables are stored. Once execution of it finished will the scope be thrown away and with it all its local variables. %SET variables are local. Nothing wrong with it. Global variables best created in WebPreferences and SitePreferences.

Think of variables as best being passed down, not being propagated upwards in a kind of sideeffect on an upper variable scope. The latter is quite an anti pattern.

-- MichaelDaum - 02 May 2018

This response provides a lot of implementation theory and details, but does not propose any solutions. In IRC, GeorgeClark suggested using Interwiki links. These could handle use cases where the variable represents a URL, but they can't be used for other situations. Also, I don't see a way to set them for a single web or subweb.

As a real-life example, I edit a monthly newsletter that contains tables of public events. To tidy up the tables, I use Set to encode (an ever-increasing collection of) venue names. I'd love to put this in a single file, rather than replicate it in each newsletter. (see http://wiki.cfcl.com/Projects/Guitar/News/2018_05).

-- RichMorin - 02 May 2018

You are trying to propagate variables upwards a nested set of scopes using a side efffect. Sorry to say that but this is bad programming.

How about a parametrized call to some %INCLUDE{"RenderNewsLetter" events="..."}%. It depends on the amount of structure per event what to recommend further. You probably may describe events by an appropriate DataForm and then use %FORMFIELD in the RenderNewsLetter function. Or a %SEARCH that renders the table of events for the monthly newsletter.

-- MichaelDaum - 03 May 2018

The tables in the newsletter pages are edited by hand, based on information from my meetup event pages. I'm not in control of the meetup software, nor am I interested in trying to write code to interact with the meetup server. So, let's assume that I will continue to do this editing by hand and that I want to do so in a way that is reasonably clean and painless.

I'm not at all sure whether (let alone how) your proposed =%INCLUDE syntax would help me in this process. Nor do I believe that it's "bad programming" to define a bunch of variables in a single file and use them in multiple places. The fact that this is difficult to do in TWiki and Foswiki is a reflection on their design, not a reflection on the use case or the approach I'm taking to solve it.

-- RichMorin - 03 May 2018

Really hard to give you any practical advice here given the amount of details.

Anyway, having a single file to defined a bunch of variables that really is WebPreferences, if you insist on global variables.

The only other advice for you I could provide is to define variables in a ConfigObject with an appropriate DataForm. And then call %INCLUDE{"RenderNewsLetter" config="MyConfig"}%. The actual implementation would read settings using %FORMFIELD{"Variable1" topic="%config%"}%, %FORMFIELD{"Variable2" topic="%config%"}% etc. Things only get cleaner if you provided more information on what you actually stored in %SET commands that is not better stored in config objects of that kind.

-- MichaelDaum - 03 May 2018

Using WebPreferences allowed me to tidy up and regularize my newsletter files. I'd rather have a separate file for these Sets, but thanks for the suggestion...

-- RichMorin - 04 May 2018

Commenting is disabled while not logged in