Create Localization Module and integrate into library file

[nate-untiedt]

Putting everything into one file would simplify deployment and make Localization more uniform with the rest of the API.

CALL Qvc.Localize('ES');

This would also be a good candidate for making extensible as well.

Thoughts?

[RobWunderlich]

I like the concept, but I think it may be premature. From the QVC user perspective I think having a separate file per language is very easy to understand and modify. What I think would be useful is some type of auto-discovery of language and other files. For example, "if you put a language.qvs file in the QvcRuntime directory we will automatically include it". I get stuck on trying to figure out where the QvcRuntime folder is.

[nate-untiedt]

I see what you are saying as far as the localization to a degree, though it still seems essentially the same as the ColorTheme concept (eg a set of related variables) to me so I don't entirely follow having the API for one and not the other.

As far as the auto discovery, was there ever a discussion about having a Qvc.Init function of sorts?

In most APIs I have used in the past, there is either a constructor or configuration function that gives the library/object any outside information necessary to do its job. In this case, having the users provide a path to a base directory that contains a prescribed folder/file naming/file type structure could provide a semi-autonomous solution (find the localization, color themeing, config, etc).

For example:

• QVC_Base Path Folder
  • Config.qvs
  • ColorTheme.xls(m|x)
  • language.qvs
  • language
    • Qvc_Language_xx.qvs
  • color
    • Qvc_Color_xx.xls(m|x)

At that point we could start making default API calls assume locations for files based on the init and have an optional flag if the user wanted to do an absolute/relative path from the application (or vice versa based on most common use/not breaking the API)

CALL Qvc.ColorTheme('Theme1')
would automatically search for QVC Base\color\Qvc_Color_Theme1.xls(m|x)

CALL Qvc.Localize('ES')
would automatically search for QVC Base\language\Qvc_Langauge_ES.qvs

and similar for any other modules that commonly needed configuration.

Users would still be able to add $(includes) anywhere they wanted but we would be providing a consistent and more succinct way of accomplishing it.

[RobWunderlich]

I like the idea of autodiscovery and possibly a Qvc.Init. The chicken and egg problem remains. How do we find Qvc.Init? I've thought about introducing a Qvc.Root variable that would be used like:
SET Qvc.Root = c:\qlikview-components;
$(Include=$(Qvc.Root)\Qvc_RunTime\qvc.qvs);

Thereafter, the fact that Qvc.Root is set will trigger auto discovery. It's the way that Qvc.Global.Extension.Directory works now.

[nate-untiedt]

I would agree, I think ultimately the user is going to have to provide the proverbial chicken somehow until Qlik implements an API that allows a script to be aware of its own file path.

One thought as far as an implementation would be that Qvc.Init would be a function defined in Qvc.qvs that the user could call. The user would pass in a root configuration path:

Sub Qvc.Init(_rootPath)
Set Qvc.Root = _rootPath;

//Do the automatic config based on Qvc.Root and any other default configuration

end Sub

So to the user:

$(Include=MyPath\Qvc_RunTime\qvc.qvs);
Call Qvc.Init(MyPath);

Either way would work. I think my object oriented programming background is showing through in wanting to encapsulate any sort of variable assignment in a function call :).

[MattFryer]

Like you Nate, coming from an OO background that would be my go to method. However, I have to keep in mind that most QVC users won't be from a software engineering background and so the best solution would for me be the one that is easiest to understand and which fits in with how the rest of QVC works. Ideally we don't change anything that might break existing user's scripts.

That all said, we do have a Qvc.Cleanup() which users are used to using, and so having a Qvc.Setup() or similar seems both logical and should be no harder for them to understand. Even if all it does is set a root path in to a variable (which is in turn killed in Qvc.Cleanup) then auto discovery can be triggered as Rob suggested.

[nate-untiedt]

That's a good reminder Matt.

Also, I like your idea of Qvc.Setup as a name better. It seems more consistent with Qvc.Cleanup() than Qvc.Init().

[RobWunderlich]

I can see arguments for both approaches.
Option 1:
SET Qvc.Root = c:\qlikview-components;
$(Must_Include=$(Qvc.Root)\Qvc_RunTime\qvc.qvs);

I like this approach because it's somewhat self-validating and feels natural. "Follow this convention..". If you have an incorrect Qvc.Root, you will find out right away. The presence of Qvc.Root will implicitly enable auto-discovery. But we should we destroy Qvc.Root in Qvc.Cleanup? To force it to be explicitly set? Or would that prevent someone from setting the variable another way?

Option 2:
$(Must_Include=$(c:\qlikview-components\Qvc_RunTime\qvc.qvs);
CALL Qvc.Setup('c:\qlikview-components')

Would we validate for the passed directory and throw an error if it doesn't exist? This makes the request for auto-discovery explicit. It also decouples the location of the local config files from the Qvc_Runtime. I may prefer it for that reason alone. But are there files in the QVC distribution we will want to autodiscover? That takes me back to using variables like Qvc.Global.Extension.Directory.

I think it's great we are visiting this topic now with a broader set of brains than when I first built the project. Given that, is there an option 3 we haven't surfaced yet? If our requirements were:

1. Make the library available to the script.
2. Auto discover local customization based on convention.

If we were starting from scratch, is there something else we would think of?

[clisboa]

Hi,

I believe option 1 is the best one, i always prefer explicit over implicit.
And it's easier to fiddle with.
The Call for Qvc.Setup seems to hide some magic, and if you need to change
the environment you have to change the path in two places instead of just
one.

As for a third option, if there's a way to know where the Alternate
Extensions Folder (
https://community.qlik.com/servlet/JiveServlet/showImage/2-626526-68315/Extension.png
) is defined we could use that. But that could be a problem for users using
only the desktop apps.

Com os melhores cumprimentos / Best Regards

Carlos Lisboa
[email protected]

On Mon, Jun 8, 2015 at 8:40 PM, RobWunderlich [email protected]
wrote:

I can see arguments for both approaches.

Option 1: SET Qvc.Root = c:\qlikview-components;
$(Must_Include=$(Qvc.Root)\Qvc_RunTime\qvc.qvs);

I like this approach because it's somewhat self-validating and feels
natural. "Follow this convention..". If you have an incorrect Qvc.Root, you
will find out right away. The presence of Qvc.Root will implicitly enable
auto-discovery. But we should we destroy Qvc.Root in Qvc.Cleanup? To force
it to be explicitly set? Or would that prevent someone from setting the
variable another way?

Option 2: $(Must_Include=$(c:\qlikview-components\Qvc_RunTime\qvc.qvs);
CALL Qvc.Setup('c:\qlikview-components')

Would we validate for the passed directory and throw an error if it
doesn't exist? This makes the request for auto-discovery explicit. It also
decouples the location of the local config files from the Qvc_Runtime. I
may prefer it for that reason alone. But are there files in the QVC
distribution we will want to autodiscover? That takes me back to using
variables like Qvc.Global.Extension.Directory.

I think it's great we are visiting this topic now with a broader set of
brains than when I first built the project. Given that, is there an option
3 we haven't surfaced yet? If our requirements were:

1. Make the library available to the script.
   1. Auto discover local customization based on convention.

If we were starting from scratch, is there something else we would think
of?

—
Reply to this email directly or view it on GitHub
#34 (comment)
.

[nate-untiedt]

Option 4 - Defaults with Configuration Profiles:

(Building on top of the decoupling idea that Rob mentioned)

• We setup a configuration/root directory (either option 1 or 2 would work, I think 2 provides the most future flexibility and consistency with the Qvc.Cleanup API)
• Within that root directory we search for the user's "default" configuration files
• Within the root directory there is a 'profiles' directory (I'm not set on the name just there for the sake of explanation) that contains subdirectories that have configuration files inside of them
• LoadProfile API would be built that could be used after Setup is called
  • This would allow users to chain profiles together by calling loadprofile multiple times if they wanted to.

CALL Qvc.LoadProfile('myProfile1');

For example:

• QVC_Base Path Folder
  • Config.qvs
  • ColorTheme.xls(m|x)
  • language.qvs
  • profiles
    • myProfile1
      • Config.qvs
      • ColorTheme.xls(m|x)
      • language.qvs

This allows for both an implicit default configuration and an explicit profile configuration.

I think there is more to be fleshed out there potentially but wanted to put this up for discussion.