I've been busily creating code that our report writers can use in such a way that they can just include a few fexes and set some pre-determined variables to make their reports behave in a standardised fashion.

However, we're starting to run into namespace collisions.

The trouble stems from the fact that every focus variable appears to be global. Now that's not too surprising, those variables are defined in the top scope, and other code is included in that same scope.
For example:

-SET &FOO = 'This very important value';

-* This include uses the value of &FOO
-INCLUDE heading.fex

-*
-* Do the reporting stuff that we created this fex for in the first place
-*
-SET &FOO = 'Some report parameter';

-* This include also uses &FOO, but it got changed in the report body
-INCLUDE footing.fex

I realise it's possible to parametrise a fex to make it behave similar to functions in other languages - that's one way to go about it.

However, many of my global variables are basically part of the same context. I can't really make them local to a function, as I need them in several places (in different include-files, for example). Having something like a struct {...} or even a class would be great!

Now I was thinking that TABLEs are in fact very similar to those types.

Perhaps it would be possible to create a virtual TABLE with related report parameters and pass that around as a global variable? Would that result in a practically useful approach? What would that look like in (Web-)FOCUS and/or DM code?

This message has been edited. Last edited by: Kerry,

Are you saying that two different requests are impacting on each other ?

As far as I am aware, Global variables will be related to a session, and each request will have a different session, and a different temp directory.

How is your WebFOCUS server installed ?
Is it Private or Pooled ?

Ah crap, you use the term 'global variable' in a different way. I mean variables global in the usual programming paradigms, not some kind of server-wide super-globals.

See the example I gave.

In WebFOCUS there are two types of amper variables.

&var is local (to the session)
&&var is global (This is a throwback from MF FOCUS)

Because your fex runs in a session, then the &var seems like a global one.

If you EX and FEX instead of -INCLUDE, then you will get a new session, and the &vars will be cleared for that session.

Because you are -INCLUDEing, the code becomes part of your main FEX, and there fore all one FEX when its running.

This is not a global, a global would have
an &&, and yep it will remain intaked, when
it is set in a fex, then and html is called,
then a fex is called, it can still use it, way easier than writting a bunch of Java to do it.
In this case all of the -INCLUDE programs are read as one focexec. It can be reset for each focexec just put a -RUN after each -INCLUDE and life will be great. Remember internals all dialog manager is resolved to a -RUN before the table code is worked.

Yes, I understand that an include gets inserted in the current scope.

What I'm looking for is to reduce the scope of &variables to a more local context (a different name-space if you like) than the session, similar to how class attributes are local to an object or how table column values are local to a table. That's probably not possible in WF, but it can't hurt to ask

The alternative would indeed be to change our includes into parametrised procedure calls (using EX or FEX), but then I would need to re-do several months of work. I'd rather not... Besides, our includes do need to interact with each-other, just not with the rest of the fex.

I'll sketch you a picture of my problem:
Our include-fexes take care of basic report styling.

• There's an initialisation fex that takes several parameters, like who's responsible for the data the report displays and what output format to use.
  
• Then there's a fex handling the footing (which contains the responsible person's name, among other things) that also includes the right style-sheet and uses the actual output format.
  
• And finally there's a tear-down fex that handles resetting parameters in case there are multiple reports combined on a single page.
  

The parameters passed to the first of these three fexes need to be available to the other fexes, but they shouldn't interact with parameters in the top fex or in other included fexes. Likewise, parameters in the top-fex or other included fexes (except for the ones used to initialise the first fex) should not affect those in the aforementioned three fexes.

I wonder if you could make use of indexed variables, then you could have sets of variables for specific uses.

e.g.
&Top.&Varname
&Footer.&Varname

All Top variables would be &Topxxxx, and footer variables would be &Footerxxxx, effectively containing the variable to a group. These would still be avaialable to the whole fex, but may identify variables in a better manner.

That looks like just what I was looking for, but I'm having a little trouble applying it. The below code works to initialise my indexed variables, but there just got to be a more convenient approach?
I've tried several ways to append the property-names directly to the indexed variable (instead of using a temporary variable with the property-name assigned to it), but all my attempts resulted in syntax errors...

-SET &N = 'FILENAME';
-SET &FOOT.&N = 'car.mas';
-SET &N = 'APPHOLD';
-SET &FOOT.&N = 'ibisample';
-SET &N = 'FOOTERTYPE';
-SET &FOOT.&N = 'TABLE';
-SET &N = 'REPORTNAME';
-SET &FOOT.&N = &FOCFEXNAME;

-? &FOOT

An Indexed variable is just a variable.

&FOOTFILENAME is the same as &FOOT.&N with &N set to FILENAME.

You could just set them.

-SET &FOOTFILENAME = 'car.mas';
-SET &FOOTAPPHOLD = 'ibisample';
-SET &FOOTFOOTERTYPE = 'TABLE';
-SET &FOOTREPORTNAME = &FOCFEXNAME;

-? &FOOT

-SET &TYPE = 'APPHOLD' ;

-TYPE FOOT.&TYPE = &FOOT.&TYPE 

The indexing is just a nice way to identify variables that start with a fixed number of characters.