Closed WedersonCD closed 4 years ago
This is very interesting. How is it different or an improvement on the native SUB feature already available in script?
This is very interesting. How is it different or an improvement on the native SUB feature already available in script?
1- Using Subs you have to know the sub name and the params, Qlik don't show which Subs are available(included) in script. Using the SSE you see a list of all available functions only be typing SSE.
2- You don't have to put yours Qlik code in Qlik Server of the client, the QVS files stay on your server, just being consumed by the client.
3- You can organize better yours Subs, like a Class in C#:
SSE.StoreTableIn.Qvd() SSE.StoreTableIn.Csv()
SSE.CreateTable.Calendar() SSE.CreateTable.Mapping() SSE.CreateTable.AsOfMonth()
4 - In a project like this, we can create a repository of commom QVS powered by Community.
Using Subs you have to know the sub name and the params, Qlik don't show which Subs are available(included) in script. Using the SSE you see a list of all available functions only be typing SSE.
True, this is an advantage.
2- You don't have to put yours Qlik code in Qlik Server of the client, the QVS files stay on your server, just being consumed by the client.
You can already put qvs files on any server and include them with $(include)
3
- You can organize better yours Subs, like a Class in C#:
SSE.StoreTableIn.Qvd() SSE.StoreTableIn.Csv()
SSE.CreateTable.Calendar() SSE.CreateTable.Mapping() SSE.CreateTable.AsOfMonth()
You can organize Subs like that as well.
4 - In a project like this, we can create a repository of commom QVS powered by Community.
You can already create common sub libs like https://github.com/RobWunderlich/Qlikview-Components.
I really appreciate the effort and creativity. But I'm not convinced that this idea belongs yet in this library. I see it duplicating the existing function of Subs and parameterized variables but with less flexibility, not more. For example, Subs can access the data model.
You can already put qvs files on any server and include them with $(include)
Yes, but It is better to have a connection with your server in the QMC than in the script editor..
You can organize Subs like that as well.
Yes, but writting Sub.Create. will not show all functions of this ''class'', like the first point on previous comment.
You can already create common sub libs like https://github.com/RobWunderlich/Qlikview-Components.
:0 I don't know that... I will definitely explore this, thank you!
I really appreciate the effort and creativity. But I'm not convinced that this idea belongs yet in this library. I see it duplicating the existing function of Subs and parameterized variables but with less flexibility, not more. For example, Subs can access the data model.
I still think that using QVS like SSE functions make subs more usable because you don't have to 'decorate' the name and the params.. but i understand your point.
I create a new generic function named 'qvsToFunction' that register functions based in QVS files, you can add more QVS puting your file in \lib\QlikScripts\qvs. The first line must be the function name, and the second line all parameters used in Qvs file. Ex: FunctionName: my_function_name Params: param1,param2,param3 in the script, use the parans with #{} Ex: RENAME FIELD #{param1} TO #{param2}; DROP TABLE #{param3};
All params will be string type and all functions will be Scalar type.
You can call function in the script using LET statement. Ex: LET variable = SSE.FunctionName('param1','param2');